from:"אורי"

OK, here is a draft PR: https://github.com/django/django/pull/14226
אורי
u...@speedy.net


On Tue, Apr 6, 2021 at 4:53 PM Carlton Gibson 
wrote:

> Hey Uri.
>
> Yes, I know Claude is busy at the moment (as I think is everyone this last
> year) but we’ll certainly need his input.
>
> For me, a small set of changes just showing what’s needed (in one place) —
> with any relevant links and “Do X, then Y, then Z” steps — helps to focus
> the discussion, and we can think about tests and so on.
>
> So, yes, a minimal draft PR, again as a proof-of-concept before you put
> too many hours in, would be very helpful. (Bottom-line is you’re probably
> the world expert here on this topic as it stands, so we need to catch up
> with you — any help you can give us in doing that goes a long way 😀)
>
> Kind Regards,
>
> Carlton
>
>
>
>
> On 6 Apr 2021, at 15:48, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
>
> Hi Carlton,
>
> Thanks for the feedback. Do you want me to create the draft PR? I would
> also like to receive feedback from Claude (cc), to see if we are in the
> right direction. Maybe it's possible to update things automatically via
> Transifex?
>
> Thanks,
> Uri.
> אורי
> u...@speedy.net
>
>
> On Tue, Apr 6, 2021 at 4:32 PM Carlton Gibson 
> wrote:
>
>> Hey Uri.
>>
>> Thanks for bumping this up — Yes, it looks like the plan is to make the
>> adjustments that you suggested on the ticket.
>>
>> I guess I’d just suggest doing a little bit as a proof-of-concept and
>> opening a Draft PR so we can have a look, and confer with Claude to approve
>> the general approach, before you put in hours updating every string. (Once
>> a PR is open, it’s always possible to collaborate too.)
>>
>> It seemed the idea was fairly clear — were there specific doubts
>> unresolved?
>>
>> Kind regards, Carlton
>>
>> On Tue, 6 Apr 2021 at 13:47, אורי  wrote:
>>
>>> Hi Adam,
>>>
>>> What will a PR require? Does it require to change all the translations
>>> in all the languages, as well as the translation keys? And how do we intend
>>> to update it with the current translations in Transifex? Do you want me to
>>> handle such a PR?
>>>
>>> Thanks,
>>> Uri.
>>> אורי
>>> u...@speedy.net
>>>
>>>
>>> On Tue, Apr 6, 2021 at 1:34 PM 'Adam Johnson' via Django developers
>>> (Contributions to Django itself) 
>>> wrote:
>>>
>>>> Hi Uri
>>>>
>>>> It depends on someone making the change. It looks like Ryan Cheley
>>>> assigned it to themselves but hasn't made a PR. Perhaps you could?
>>>>
>>>> Thanks,
>>>>
>>>> Adam
>>>>
>>>> ‪On Tue, 6 Apr 2021 at 11:17, ‫אורי‬‎  wrote:‬
>>>>
>>>>> Hi,
>>>>>
>>>>> https://code.djangoproject.com/ticket/31937
>>>>>
>>>>> Any chance this will be fixed before the next major release? (4.0).
>>>>>
>>>>> Remember it will also take time to fix the relevant translations - I
>>>>> estimate it will take ~2 months to fix them before they are released to
>>>>> production.
>>>>>
>>>>> In English too, I suggest using the "one" word instead of "1", for
>>>>> example "one week" instead of "1 week". But it's more a mistake in Hebrew
>>>>> (and Arabic), where there is a word for two weeks (שבועיים), and writing 
>>>>> "2
>>>>> weeks" (2 שבועות) is incorrect.
>>>>>
>>>>> Thanks,
>>>>> Uri.
>>>>>
>>>>>
>>>>> אורי
>>>>> u...@speedy.net
>>>>>
>>>>> --
>>>>> 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/CABD5YeH8ciWq-f6Myb-jnkm1pK4%2Brrd%2B6sQes2z64U8qON23vQ%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/django-developers/CABD5YeH8ciWq-f6Myb-jnkm1pK4%2Brrd%2B6sQes2z64U8qON23vQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .

Re: Can't translate strings properly to Hebrew and Arabic (#31937)

Hi Carlton,

Thanks for the feedback. Do you want me to create the draft PR? I would
also like to receive feedback from Claude (cc), to see if we are in the
right direction. Maybe it's possible to update things automatically via
Transifex?

Thanks,
Uri.
אורי
u...@speedy.net


On Tue, Apr 6, 2021 at 4:32 PM Carlton Gibson 
wrote:

> Hey Uri.
>
> Thanks for bumping this up — Yes, it looks like the plan is to make the
> adjustments that you suggested on the ticket.
>
> I guess I’d just suggest doing a little bit as a proof-of-concept and
> opening a Draft PR so we can have a look, and confer with Claude to approve
> the general approach, before you put in hours updating every string. (Once
> a PR is open, it’s always possible to collaborate too.)
>
> It seemed the idea was fairly clear — were there specific doubts
> unresolved?
>
> Kind regards, Carlton
>
> On Tue, 6 Apr 2021 at 13:47, אורי  wrote:
>
>> Hi Adam,
>>
>> What will a PR require? Does it require to change all the translations in
>> all the languages, as well as the translation keys? And how do we intend to
>> update it with the current translations in Transifex? Do you want me to
>> handle such a PR?
>>
>> Thanks,
>> Uri.
>> אורי
>> u...@speedy.net
>>
>>
>> On Tue, Apr 6, 2021 at 1:34 PM 'Adam Johnson' via Django developers
>> (Contributions to Django itself) 
>> wrote:
>>
>>> Hi Uri
>>>
>>> It depends on someone making the change. It looks like Ryan Cheley
>>> assigned it to themselves but hasn't made a PR. Perhaps you could?
>>>
>>> Thanks,
>>>
>>> Adam
>>>
>>> ‪On Tue, 6 Apr 2021 at 11:17, ‫אורי‬‎  wrote:‬
>>>
>>>> Hi,
>>>>
>>>> https://code.djangoproject.com/ticket/31937
>>>>
>>>> Any chance this will be fixed before the next major release? (4.0).
>>>>
>>>> Remember it will also take time to fix the relevant translations - I
>>>> estimate it will take ~2 months to fix them before they are released to
>>>> production.
>>>>
>>>> In English too, I suggest using the "one" word instead of "1", for
>>>> example "one week" instead of "1 week". But it's more a mistake in Hebrew
>>>> (and Arabic), where there is a word for two weeks (שבועיים), and writing "2
>>>> weeks" (2 שבועות) is incorrect.
>>>>
>>>> Thanks,
>>>> Uri.
>>>>
>>>>
>>>> אורי
>>>> u...@speedy.net
>>>>
>>>> --
>>>> 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/CABD5YeH8ciWq-f6Myb-jnkm1pK4%2Brrd%2B6sQes2z64U8qON23vQ%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/django-developers/CABD5YeH8ciWq-f6Myb-jnkm1pK4%2Brrd%2B6sQes2z64U8qON23vQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>> 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/CAMyDDM2%3Di0HHqMEuoiJTZB_fkJeta61pE6yT0OqgfE9x4TYZpA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2%3Di0HHqMEuoiJTZB_fkJeta61pE6yT0OqgfE9x4TYZpA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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/CABD5YeGA%3D9EATOwvop50FovOVfmKG1SZeV5nc3O_xGPO73wS5A%40mail.gmail.com
>> <https://groups

Re: Adding ability to choose AutoField type (signed vs unsigned)

Hi,

I think any primary key field which is an integer should be 64 bits
unsigned. 32 bits integers belong to the history, and there is no need for
negative primary keys. It's like when they defined IPv4, they defined it
with 32 bits and now we are stuck forever with 32 bits IP addresses. You
can never know when a model will require more than 2**31 records and I
don't see any use in using 32 bits in 2021.

By the way, if we use 64 bits - it doesn't matter that much if the integer
is signed or unsigned - I don't think we need the 64th bit anyway.

Uri.
אורי
u...@speedy.net


On Tue, Apr 6, 2021 at 3:12 PM Caio Ariede  wrote:

> Hello folks,
>
> Now that we’ve completed these:
>
> https://code.djangoproject.com/ticket/31007
> https://code.djangoproject.com/ticket/30987
>
> I’m wondering if https://code.djangoproject.com/ticket/56 is still
> something we want to solve.
>
> I feel like the workaround would be to explicitly define ``id =
> models.PositiveBigIntegerField(primary_key=True)``
>
> In the other hand, we could also add ``PositiveBigAutoField`` to make
> things easier now that we have the ability to define the
> ``default_auto_field`` per app.
>
> Thoughts?
>
> — Caio
> On 12 Apr 2020 15:01 -0300, Jure Erznožnik ,
> wrote:
>
> I would like to try again:
> I believe having a general setting for autofields could cause all
> sorts of issues. As illustrated, I immediately thought that some
> people might want to use that for migrating to UUID fields for that (I
> read about using them somewhere about when I started using Django 5
> years ago). The point is that an option like that immediately sparks
> imagination.
>
> However, the problem being attempted at here is only migrating from
> signed to unsigned integer. A very minor change most deployments would
> not even be affected by.
>
> That one could be handled less aggressively by:
>
> OTOH, JUST FOR the unsigned vs signed integer PK, it should be relatively
> easy to modify makemigrations code detect existing migrations for the
> model, detect that the only difference is IntegerField vs
> PositiveIntegerField and in this case skip generating the migration (for
> migrating the field to an unsigned one). There could also be a flag to the
> management command specifying to force generating said migrations.
>
>
> I believe this would be unintrusive enough allowing everyone to
> migrate their models at will. Since most of users won't even notice
> the difference, a solution like this could be preferable even if it
> introduces one additional special case in the code.
> OTOH, the proposed setting DOES provide more flexibility (to introduce
> more varied options for the PK field), but a necessity for a
> biginteger or guid or anything else, for that matter, is already
> catered for in the API - by specifying the super-special pk manually
> for the affected table.
>
> I sure hope I'm not just derailing the discussion with my uninformed
> ideas, but perhaps the minor change could be handled in a simpler
> manner like proposed above.
>
> LP,
> Jure
>
> On Sat, Apr 11, 2020 at 12:21 AM Caio Ariede 
> wrote:
>
>
> I believe that it is already possible to trigger new migrations in a
> third-party app by changing its AppConfig.label, for example. Please
> correct me if I’m wrong.
>
> From that perspective, it think it wouldn’t be wrong if a migration is
> created after someone changes its AppConfig’s default_auto_field. The extra
> migrations could be handled manually using MIGRATION_MODULES.
>
> I feel like adding such option to AppConfig would give a pretty good
> flexibility, but I’m not sure it dismisses the use of
> settings.DEFAULT_AUTO_FIELD. Specially if one desires to keep an old
> default behavior.
>
> --
> Caio
>
>
>
> On Apr 10, 2020, at 04:29, Nick Pope  wrote:
>
> People can also choose to set this for a third-party app by subclassing
> the AppConfig, but as you say, they'd then be forced to handle migrations
> manually - is this even avoidable? I'm not sure how this would look for
> moving to a new default though.
>
>
> --
> 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/3FE8A93E-1A7F-436D-87CC-3D87A6C16801%40gmail.com
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group

Re: Can't translate strings properly to Hebrew and Arabic (#31937)

Hi Adam,

What will a PR require? Does it require to change all the translations in
all the languages, as well as the translation keys? And how do we intend to
update it with the current translations in Transifex? Do you want me to
handle such a PR?

Thanks,
Uri.
אורי
u...@speedy.net


On Tue, Apr 6, 2021 at 1:34 PM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Hi Uri
>
> It depends on someone making the change. It looks like Ryan Cheley
> assigned it to themselves but hasn't made a PR. Perhaps you could?
>
> Thanks,
>
> Adam
>
> ‪On Tue, 6 Apr 2021 at 11:17, ‫אורי‬‎  wrote:‬
>
>> Hi,
>>
>> https://code.djangoproject.com/ticket/31937
>>
>> Any chance this will be fixed before the next major release? (4.0).
>>
>> Remember it will also take time to fix the relevant translations - I
>> estimate it will take ~2 months to fix them before they are released to
>> production.
>>
>> In English too, I suggest using the "one" word instead of "1", for
>> example "one week" instead of "1 week". But it's more a mistake in Hebrew
>> (and Arabic), where there is a word for two weeks (שבועיים), and writing "2
>> weeks" (2 שבועות) is incorrect.
>>
>> Thanks,
>> Uri.
>>
>>
>> אורי
>> u...@speedy.net
>>
>> --
>> 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/CABD5YeH8ciWq-f6Myb-jnkm1pK4%2Brrd%2B6sQes2z64U8qON23vQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CABD5YeH8ciWq-f6Myb-jnkm1pK4%2Brrd%2B6sQes2z64U8qON23vQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> 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/CAMyDDM2%3Di0HHqMEuoiJTZB_fkJeta61pE6yT0OqgfE9x4TYZpA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2%3Di0HHqMEuoiJTZB_fkJeta61pE6yT0OqgfE9x4TYZpA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeGA%3D9EATOwvop50FovOVfmKG1SZeV5nc3O_xGPO73wS5A%40mail.gmail.com.

Can't translate strings properly to Hebrew and Arabic (#31937)

Hi,

https://code.djangoproject.com/ticket/31937

Any chance this will be fixed before the next major release? (4.0).

Remember it will also take time to fix the relevant translations - I
estimate it will take ~2 months to fix them before they are released to
production.

In English too, I suggest using the "one" word instead of "1", for example
"one week" instead of "1 week". But it's more a mistake in Hebrew (and
Arabic), where there is a word for two weeks (שבועיים), and writing "2
weeks" (2 שבועות) is incorrect.

Thanks,
Uri.


אורי
u...@speedy.net

-- 
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/CABD5YeH8ciWq-f6Myb-jnkm1pK4%2Brrd%2B6sQes2z64U8qON23vQ%40mail.gmail.com.

Re: Bug with order_by and reverse on a __in exclusion query

2021-03-29 Thread אורי

Did you open a ticket?

https://code.djangoproject.com/


אורי
u...@speedy.net


On Mon, Mar 29, 2021 at 11:18 PM Nathaniel Brown  wrote:

> Basically when I try to exclude all members that have cancelled standing
> from all the poems it breaks and includes all Poems no matter if the member
> was cancelled.
>
> You can remove the order_by and reverse clauses on the poems_created and
> the list shows fine, yet when I add a order_by it has no effect. And when I
> add the reverse it does as previously explained, shows all poems no matter
> if the member was cancelled.
>
> Member has lets say two fields, a User pk and a standing; a Poem has
> created by and a Title with a submitter relating to the User pk.
>
> Here is the sample code:
>
> members_cancelled =
> Member.objects.exclude(standing=settings.MEMBER_STANDING_CANCELLED).values_list('pk',
> flat=True)
> poems_created =
> Poem.objects.exclude(submitter__in=list(members_cancelled),
> hidden=True).order_by('created').reverse()
>
> Thanks in advance in you've got this far.
>
> Nate
>
> --
> 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/c76e2a29-e036-495b-8b03-397b943217b9n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c76e2a29-e036-495b-8b03-397b943217b9n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeEGp6Y1vEFvUmBhHTn3SWMBoqKdBeXp%3DBgqAXbOQSfvDA%40mail.gmail.com.

Re: Deprecating django.utils.functional.cached_property() ?

2021-02-04 Thread אורי

Is there any difference in the implementation between the two
*cached_property*?
אורי
u...@speedy.net


On Thu, Feb 4, 2021 at 12:57 PM Carlton Gibson 
wrote:

> functools.cached_property is available from Python 3.8.
>
> https://docs.python.org/3.9/library/functools.html#functools.cached_property
>
> Is there any benefit to maintaining our own version, or should we
> deprecate django.utils.functional.cached_property() with Django 4.0?
>
> Thanks.
> 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/dff05f70-4204-487d-a918-d4918d9b3f0en%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/dff05f70-4204-487d-a918-d4918d9b3f0en%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeGG5RbbQrk4wSkCZ7CN_8Rr6nSJO54sUOQHgs6DOP-RKg%40mail.gmail.com.

Re: final_catch_all_view

2021-01-19 Thread אורי

Hi Adam,

I think it's better not to rely on the number of "catch all" urlpatterns to
be 1. I suggest it's better to separate *AdminSite.get_urls* into 3
functions - one returning all urls like before (without the "catch all"
urlpattern), one returning a list containing only the "catch all"
urlpattern, and one calling both functions and concatenating the lists.
This way I will be able to define the first function in my own AdminSite
class, add my own urlpatterns and return the list, and Django will do
everything else for me. Instead of using *urls[:-1]* and *urls[-1]*, there
should be functions returning these lists, which I will be able to override
and add my own urlpatterns. I think this approach is better than relying on
the number of "catch all" urlpatterns to be 1.

Also, this feature will break all Django admin sites, unless the name of
the function *AdminSite.get_urls* will remain the same and this function
will not change, but the 2 other functions will be new functions and Django
will call the third function (with all urls) instead of calling
*AdminSite.get_urls*.

אורי
u...@speedy.net


On Tue, Jan 19, 2021 at 6:55 PM Adam Johnson  wrote:

> I don't see the need for any change - you can insert your custom URL's
> before the catch-all view with a subclass of AdminSite like so:
>
> class MyAdminSite(AdminSite):
> def get_urls(self):
> urls = super().get_urls()
> return urls[:-1] + [
> # custom urls
> ...
> ] + urls[-1]
>
> ‪On Tue, 19 Jan 2021 at 16:06, ‫אורי‬‎  wrote:‬
>
>> Hi,
>>
>> I installed Django 3.2 alpha and found out the change related to
>> *final_catch_all_view*. I use *AdminSite* in my websites and I added
>> some urlpatterns to the default urlpatterns. However, I want my urlpatterns
>> to be after Django core's urlpatterns and not before them, so if a Django
>> core urlpatterns matches a URL, it should be applied before my
>> own urlpatterns. I read that it's not recommended to set
>> *AdminSite.final_catch_all_view* to false, and I think it should be
>> better that the "catch all" urlpattern will be applied after all
>> urlpatterns, including those I defined in my website. Is it possible to add
>> the "catch all" urlpattern as the very last urlpattern, after the website's
>> defined urlpatterns? I think this makes more sense.
>>
>> Thanks,
>> אורי
>> u...@speedy.net
>>
>> --
>> 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/CABD5YeF_ezAHFSwj-X8oT%3DT3%2B%3D1x%3DsC4ZH%3D7QyPshWra9__H2A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CABD5YeF_ezAHFSwj-X8oT%3DT3%2B%3D1x%3DsC4ZH%3D7QyPshWra9__H2A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> 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/CAMyDDM18v4qHBem%3D8HphoJWXZJ03bwSe8r_xpRVSnd3no8W9bg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM18v4qHBem%3D8HphoJWXZJ03bwSe8r_xpRVSnd3no8W9bg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeEHrLnKQ9jLu3jcx-9cnj3RzZyo9sw5oUcxJD06LGWpvw%40mail.gmail.com.

final_catch_all_view

2021-01-19 Thread אורי

Hi,

I installed Django 3.2 alpha and found out the change related to
*final_catch_all_view*. I use *AdminSite* in my websites and I added
some urlpatterns to the default urlpatterns. However, I want my urlpatterns
to be after Django core's urlpatterns and not before them, so if a Django
core urlpatterns matches a URL, it should be applied before my
own urlpatterns. I read that it's not recommended to set
*AdminSite.final_catch_all_view* to false, and I think it should be better
that the "catch all" urlpattern will be applied after all urlpatterns,
including those I defined in my website. Is it possible to add the "catch
all" urlpattern as the very last urlpattern, after the website's defined
urlpatterns? I think this makes more sense.

Thanks,
אורי
u...@speedy.net

-- 
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/CABD5YeF_ezAHFSwj-X8oT%3DT3%2B%3D1x%3DsC4ZH%3D7QyPshWra9__H2A%40mail.gmail.com.

Re: Technical Board Decision Needed: Admin append_slash behaviour.

2021-01-06 Thread אורי

Hi,

For security reasons, I would recommend protecting any url which starts
with /admin/ (or the website's admin url prefix) with an HTTPS password
from the web server directly (such as Nginx or Apache), so that even the
login to the admin will be protected. You may consider adding this
suggestion to Django's documentation. For example, if you enter
https://en.speedy.net/admin/accounts/user/ you will be asked for an HTTPS
authentication password. Only if you know the password, then you will be
redirected to the login page, and only after you login you will be able to
view the admin views. This increases security, as you will have to login
twice. In my opinion you can consider adding this suggestion to Django's
documentation.

Thanks,
Uri Rodberg
Speedy Net
אורי
u...@speedy.net


On Wed, Jan 6, 2021 at 11:43 AM Carlton Gibson 
wrote:

> Hi all,
>
> I need to ask for a Technical Board decision on the resolution of Ticket
> #31747.
>
> Ticket #31747: Avoid potential admin model enumeration
> https://code.djangoproject.com/ticket/31747
>
> PR #13134: Fixed #31747 -- Fixed model enumeration via admin URLs.
> https://github.com/django/django/pull/13134
>
>
> ## Summary
>
> The initial issue is that there is a difference in HTTP response code for
> admin
> URLs depending on whether a URL routes to an existing model or not:
>
>http://127.0.0.1:8000/admin/auth/user/ -> 302 to login
>http://127.0.0.1:8000/admin/auth/group/ -> 302 to login
>http://127.0.0.1:8000/admin/auth/foo/ -> 404
>
> In principle an attacker could use this to leak information about the app's
> models, which could be part of a further attack.
>
> This was originally reported to the Django Security Team, who declined to
> take
> it as a security issue, but recommended adding a final catch-all view to
> the
> admin, which would redirect all unauthenticated requests to login, thus
> masking
> the private model info.
>
> Jon Dufresne picked this issue up, and submitted a PR, but in so-doing
> noticed
> that a very similar (the same?) issue occurred with APPEND_SLASH behaviour
> in
> the admin too. (Try URLs without the slash, looking for a redirect to the
> correct URL **before** being redirected to login.)
>
> The initial thought was that we might need to remove APPEND_SLASH URL
> normalisation for the admin. We were able to avoid that by restricting the
> append_slash-style URL normalisation for the admin to authenticated staff
> users. This addresses the main force of the original report (which is
> unauthenticated users remotely probing the site) but Jon noted that it
> still
> allows a staff-user to potentially discover the existence of model for
> which
> they don't have permissions in this way.
>
> In order to avoid this last threat Jon felt that we still needed to disable
> append slash URL normalisation for the admin.
>
> In contrast, I felt the threat of a staff user discovering models in this
> way
> would apply to only a tiny fraction of all installations, and that the
> utility
> of URL normalisation vastly outweighs that on balance.
>
> We have a trade-off between balancing privacy and usability here.
>
> After much discussion and thought, Jon and I came to agree (I think 🙂)
> that an
> `AdminSite.append_slash` toggle was needed to control the behaviour here.
> If
> privacy is paramount, you can set that to `False` to disable the URL
> normalisation in the admin. If you don't need to keep models secret from
> staff
> users you can have it `True` and still get the benefits of append slash
> behaviour.
>
> We felt this was something that everyone could live with. Wherever you are
> on
> the spectrum, for the simplest case, where you're just using the default
> admin
> site, you toggle the behaviour with a single line in your URL conf:
>
> from django.contrib import admin
>
> admin.site.append_slash = ...set True/False as you want here...
>
> (On the way, we also found a way of opting-out for a single ModelAdmin, but
> let's not talk about that here.)
>
> All good, except...
>
> ## Decision needed
>
> Jon and I still don't agree on the correct default value for
> `AdminSite.append_slash`.
>
> Our disagreement is a difference in weighting, which is hard to argue
> about,
> and we don't want to fall out over it either. So we'd like to ask the
> Technical
> Board to decide.
>
>
> ### Option 1 - default `True`
>
> As the PR stands:
> https://github.com/django/django/pull/13134
>
> * `AdminSite.append_slash` defaults to `True`.
> * This is consistent with the past behaviour for authenticated staff
> users.
>
>
> ### Option 2 - defaul

Re: Primary Key AutoField -> UUID Field

2020-11-14 Thread אורי

Hi Brian,

In Speedy Net we use a randomly generated string of digits, either 15
digits or 20 digits, as a primary key in all our models. We never
use auto-incrementing integers as primary keys. You can take a look at our
implementation, especially class *BaseModel* which is the base class for
all our models, and class *TimeStampedModel *(most of our models inherit
from *TimeStampedModel*):

https://github.com/speedy-net/speedy-net/blob/master/speedy/core/base/models.py

We also defined managers with querysets in which *bulk_create()* and
*delete()* are disabled.

Uri Rodberg, Speedy Net.
אורי
u...@speedy.net


On Sat, Nov 14, 2020 at 6:32 PM Brian Carter 
wrote:

> Feature Request:
>
> I like to use the UUIDField as the primary key in my models, and I think
> it would be nice to have django expose a setting in the settings.py to
> override the default primary key on models.
>
> Currently, if I don’t specify a field as the primary key, Django
> automatically uses an AutoField (auto-incrementing integer). I’d like to be
> able to automatically use a UUID field, but then still be overridden in a
> specific model if I specify a different primary key.
>
> Brian Carter
> brianrcarte...@gmail.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/EAF4690E-C862-4C68-A7DD-C2979F19BC3C%40gmail.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/CABD5YeFqeRfd6%2BMuMdzsagvjKdNu-iEDND-omuePX9TEw9TGTw%40mail.gmail.com.

Re: Ticket update ending up in gmail spam

2020-10-22 Thread אורי

Hi,

Mail I received from djangoproject.com in 2019 had SPF pass (by best guess
record). Mail I received from djangoproject.com in 2020 had SPF neutral.
Maybe you should update the SPF records for djangoproject.com.

Uri.
אורי
u...@speedy.net


On Thu, Oct 22, 2020 at 6:21 PM Peter Inglesby 
wrote:

> Hi folks,
>
> An email with an update on ticket that I'm subscribed to has ended up in
> my gmail spam folder:
>
> [image: image.png]
>
> I'm not sure what to suggest!
>
> Peter.
>
> --
> 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/CAENJrP%3DkH29Yq%3D3AsMpmyYSavD884pZ%3D%2B_MCVxnn7DLv4MhnVw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAENJrP%3DkH29Yq%3D3AsMpmyYSavD884pZ%3D%2B_MCVxnn7DLv4MhnVw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeFg9-MNhpgDhE%2BBtheGLe9%3DNAL7CaUZfzTAj_00W%2BPR%3DA%40mail.gmail.com.

Re: What the purpose of having function that is not working correctly?

2020-09-10 Thread אורי

On Thu, Sep 10, 2020 at 12:17 PM Alexander Lyabah 
wrote:

>
> Also, want to say it again, English is not my first language, and some
> words may sound not polite at all. It is not my intention, I respect all
> the work you have done with Django, and very thankful for continue working
> on it.
>

+1

-- 
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/CABD5YeFT5emMQ%2B9h%2B9U8t%2B_cHVDcLWwyL84QNEw11p75tZV66Q%40mail.gmail.com.

Re: command for stopping server

2020-09-07 Thread אורי

I think the server run by "python manage.py runserver" is just a debugging
server, it is not suitable for production. For production you run a web
server such as Nginx or Apache which you configure to execute Django.
אורי
u...@speedy.net


On Mon, Sep 7, 2020 at 4:37 PM Antonín Drdácký  wrote:

> Hello there,
>
> This question on StackOverflow is a workaround for stopping the server
>
> https://stackoverflow.com/questions/27066366/django-development-server-how-to-stop-it-when-it-run-in-background
>
> Basically I would like to run the server and stop it by a program, it is
> hard, when the default way is literally "pressing ctrl+C",
> killing the process is different on different OS'es.
> When searching the web (StackOverflow) users replies to individual answers
> were "This worked for me." or "This didn't work for me.",
> this showcases that different conditions make it hard to get to actually
> stopping the server.
>
> A unified solution would be very nice. If we want to keep "python
> manage.py runserver" together with "press ctrl+C to quit",
> then I would suggest a new command, let's call it "startserver", that
> would be non-blocking, running subprocess, or something,
> once the user is done he simply calls "stopserver" to stop it.
> "startserver" vs "runserver" might be similar for some, suggest different
> command name if you like.
>
> It is only my suggestion, I don't care if it will be more complicated as
> long as it will "just work" on all OS'es and will be clear to use.
>
> Thanks for your time and consideration
> Antonín Drdácký
>
> --
> 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/CALALaaN-e-qQ%3DBLuGb4QVAx%2BpEDxWaiRAWFoPnDGoPkNv_Of-w%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CALALaaN-e-qQ%3DBLuGb4QVAx%2BpEDxWaiRAWFoPnDGoPkNv_Of-w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeE2howmrCruPmbALRV7UKACCjrSCJ0_%3D9rRmpFXhpKVYQ%40mail.gmail.com.

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

2020-09-03 Thread אורי

On Thu, Sep 3, 2020 at 11:57 AM Tom Forbes  wrote:

> You might have a point regarding the frequency of bumping the PBKDF
> iteration setting. Is bumping it 5 times in 13 months really required? On
> the other hand you might want to consider staying on the LTS releases and
> avoid issues such as this, and the issue you’re describing is quite niche.
>
> However, I would say that based on your previous posts to this mailing
> lists around authentication that you are definitely in need of some form of
> federated login/SSO for your several web properties. That would certainly
> alleviate this issue and some of the other problems you’ve reported here.
>

Thank you for your suggestions. I was not aware that upgrading to non-LTS
releases will log out users. It's good to know now.

-- 
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/CABD5YeE2tMF7eLAtCGEEXc0rXj_kYv0BWVcD63ffNvdOcQuVbg%40mail.gmail.com.

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

2020-09-03 Thread אורי

Hi,

To conclude, I think it would be better to change the number of iterations
not every 8 months, but every 2 years (with a new LTS release).

אורי
u...@speedy.net


On Thu, Sep 3, 2020 at 10:29 AM Florian Apolloner 
wrote:

> I do not think there is anything to reopen because it works as designed.
> Password changes cause other browser sessions to be terminated because the
> session auth hash no longer matches.  You can use a custom user model and
> override `get_session_auth_hash` but the defaults won't change, sorry.
>
> On Thursday, September 3, 2020 at 4:56:13 AM UTC+2 Uri wrote:
>
>> Django developers,
>>
>> I would like to reopen #31970
>> <https://code.djangoproject.com/ticket/31970>. In short, the problem is
>> - if a user is logged in with more than one browser, and when we upgrade
>> Django to any version which *PBKDF2PasswordHasher.iterations* changes
>> (which is *any* new version), and then the user logs in again - this
>> logs them out from all other browsers. I think this is a bug.
>>
>> I found out that this can be avoided by changing *def must_update*, for
>> example if you change it to something like:
>>
>> def must_update(self, encoded):
>> # Update the stored password only if the iterations diff is at least 
>> 250,000.
>> algorithm, iterations, salt, hash = encoded.split('$', 3)
>> iterations_diff = abs(self.iterations - int(iterations))
>> return ((int(iterations) != self.iterations) and (iterations_diff >= 
>> 25))
>>
>> Or even simply:
>>
>> def must_update(self, encoded):
>> return False
>>
>>
>> אורי
>> u...@speedy.net
>>
> --
> 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/87b16804-3da2-46b7-8ff5-466cd2f38aa2n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/87b16804-3da2-46b7-8ff5-466cd2f38aa2n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeHppQW8gc5-eg3-wN-7wSVXWumPvYVAZD5OTW9PnGtCTA%40mail.gmail.com.

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

2020-09-03 Thread אורי

Hi,

On Thu, Sep 3, 2020 at 11:23 AM Shai Berger  wrote:

>
> Please be aware that this is a security issue. The passwords are
> encrypted as protection for the case that they fall into the hands of
> an attacker, but for this protection to be effective, it must stay hard
> and costly to brute-force them. The number of iterations is enlarged in
> order to keep this cost up with the improvements of available hardware.
> If you intend to keep a user's password un-updated for many years, it's
> almost as bad as keeping it in plaintext -- in 10-15 years, we'd expect
> the number of iterations in current Django to be grossly insufficient.

I don't intend to keep the settings of now for 10-15 years. But since I
launched Speedy Net in Django 1.11 in production 13 months ago, I upgraded
to 2.0, 2.1, 2.2, 3.0 and now 3.1. These are 5 major version upgrades in 13
months. I don't see a reason why the number of iterations should have
changed 5 times in 13 months. Even if I would upgrade Django every 8
months, I prefer to keep the number of iterations and change it every 2-3
years, if this logs out users. I'm not sure if I'll write a blog post, but
you can see our patch on GitHub:

https://github.com/speedy-net/speedy-net/blob/master/speedy/core/patches/session_patches.py

I wish I knew about this issue before and then I would have patched
something like this before, before causing this to change 5 times in
production.

אורי.

-- 
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/CABD5YeFp_9btTbguvBDyUxCaaYcX4VD9thsddp7hdRqVL%2BJnuw%40mail.gmail.com.

Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

2020-09-02 Thread אורי

Django developers,

I would like to reopen #31970 <https://code.djangoproject.com/ticket/31970>.
In short, the problem is - if a user is logged in with more than one
browser, and when we upgrade Django to any version which
*PBKDF2PasswordHasher.iterations* changes (which is *any* new version), and
then the user logs in again - this logs them out from all other browsers. I
think this is a bug.

I found out that this can be avoided by changing *def must_update*, for
example if you change it to something like:

def must_update(self, encoded):
# Update the stored password only if the iterations diff is at
least 250,000.
algorithm, iterations, salt, hash = encoded.split('$', 3)
iterations_diff = abs(self.iterations - int(iterations))
return ((int(iterations) != self.iterations) and (iterations_diff
>= 25))

Or even simply:

def must_update(self, encoded):
return False


אורי
u...@speedy.net

-- 
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/CABD5YeGAGHjA-jCEEcJbMmp7i2XFUZ4w7u7Waz-YMo5gYRPQpA%40mail.gmail.com.

Using directory locale with init.py

2020-09-02 Thread אורי

Django developers,

I had an exception because of using a directory locale with __init__.py,
but I followed Django, which also uses a directory locale with __init__.py.
It seems that there is a module *locale *in Python that can't be used with
a local directory locale.

https://stackoverflow.com/a/49237311/1412564

https://github.com/django/django/tree/master/django/conf/locale

Do you think it's a good idea to use a directory locale with __init__.py?

This is the error message I received:

$ python tests_manage.py test
Traceback (most recent call last):
  File "tests_manage.py", line 14, in 
execute_from_command_line(sys.argv)
  File
"E:\Uri\Speedy_Net\Git\speedy-net-public\.venv\lib\site-packages\django\core\management\__init__.py",
line 401, in execute_from_command_line
utility.execute()
  File
"E:\Uri\Speedy_Net\Git\speedy-net-public\.venv\lib\site-packages\django\core\management\__init__.py",
line 334, in execute
parser = CommandParser(usage='%(prog)s subcommand [options] [args]',
add_help=False, allow_abbrev=False)
  File
"E:\Uri\Speedy_Net\Git\speedy-net-public\.venv\lib\site-packages\django\core\management\base.py",
line 50, in __init__
super().__init__(**kwargs)
  File "C:\Program Files\Python36\lib\argparse.py", line 1637, in __init__
self._positionals = add_group(_('positional arguments'))
  File "C:\Program Files\Python36\lib\gettext.py", line 612, in gettext
return dgettext(_current_domain, message)
  File "C:\Program Files\Python36\lib\gettext.py", line 575, in dgettext
codeset=_localecodesets.get(domain))
  File "C:\Program Files\Python36\lib\gettext.py", line 510, in translation
mofiles = find(domain, localedir, languages, all=True)
  File "C:\Program Files\Python36\lib\gettext.py", line 482, in find
for nelang in _expand_lang(lang):
  File "C:\Program Files\Python36\lib\gettext.py", line 206, in _expand_lang
loc = locale.normalize(loc)
AttributeError: module 'locale' has no attribute 'normalize'
(.venv)

אורי
u...@speedy.net

-- 
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/CABD5YeEimeugNrwFsi9mYZ0kaDRzs%2B0122dDq55G8WAnsbGK3A%40mail.gmail.com.

Re: Italic

2020-08-26 Thread אורי

Thank you.
אורי
u...@speedy.net


On Thu, Aug 27, 2020 at 9:13 AM Carlton Gibson 
wrote:

> I think it means that the ticket recently changed state, so that it no
> longer matches the query.
> (I’m not sure of the underlying mechanism there…)
>
> On 27 Aug 2020, at 08:05, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
>
> Hi,
>
> I queried tickets from  https://code.djangoproject.com/  and one ticket
> is in Italic. What does it mean?
>
> Thanks,
> אורי
> u...@speedy.net
>
> --
> 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/CABD5YeFhF%2Be754rJPvLwVF9d8QRKZgkGL%2BhepQ5ow%2BwOb1%2BN8g%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CABD5YeFhF%2Be754rJPvLwVF9d8QRKZgkGL%2BhepQ5ow%2BwOb1%2BN8g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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/827396DF-2818-4BA1-822A-6021C60B2F1A%40gmail.com
> <https://groups.google.com/d/msgid/django-developers/827396DF-2818-4BA1-822A-6021C60B2F1A%40gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeGj1LnvgCid9TYECkAyDhtKDrnbixD745QeQ5Rhgktd%3DQ%40mail.gmail.com.

Italic

2020-08-26 Thread אורי

Hi,

I queried tickets from  https://code.djangoproject.com/  and one ticket is
in Italic. What does it mean?

Thanks,
אורי
u...@speedy.net

-- 
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/CABD5YeFhF%2Be754rJPvLwVF9d8QRKZgkGL%2BhepQ5ow%2BwOb1%2BN8g%40mail.gmail.com.

Re: Regression in Set-Cookie which affects Django users

2020-08-23 Thread אורי

On Sun, Aug 23, 2020 at 8:19 AM Mariusz Felisiak 
wrote:

> It's not about the number of lines but about our backporting policy
> <https://docs.djangoproject.com/en/3.1/internals/release-process/>. We
> don't backport new features. Moreover Django 2.2 and 3.0 are in extended
> support. Per our backporting policy this means it doesn't qualify for a
> backport.
>

  OK, I will try to fork Django and backport it myself. Thank you.

אורי
u...@speedy.net

-- 
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/CABD5YeEcTa%3DPveAvw7y0aker3U5hHcSy1jJoP298Hns9h9es2Q%40mail.gmail.com.

Re: Regression in Set-Cookie which affects Django users

Hi,

I looked at it and I think PR #11894 should be backported to all working
versions of Django. It doesn't look like it will introduce new bugs or
regressions. All I need is these 2 lines:


if samesite.lower() not in ('lax', 'strict'):
raise ValueError('samesite must be "lax" or "strict".')
if samesite.lower() not in ('lax', 'none', 'strict'):
raise ValueError('samesite must be "lax", "none", or "strict".')

And the relevant documentation. This will allow setting cookies explicitly
to SameSite=None. Since Django 2.2 should be supported until 2022, I think
it makes sense to backport it to Django 2.2 and 3.0.

אורי
u...@speedy.net


On Sat, Aug 22, 2020 at 9:48 PM Mariusz Felisiak 
wrote:

> We decided that it's a new feature that will not be backported to Django
> 3.0, see #30862 <https://code.djangoproject.com/ticket/30862>, and
> discussion in PR <https://github.com/django/django/pull/11894> (with few
> simple workarounds).
>
> 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/8d09195c-b15a-4d1c-9f5c-277b5af2df3cn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/8d09195c-b15a-4d1c-9f5c-277b5af2df3cn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeECAyu49KimB9EdE%2BgrqaN208EfUWiFpdQF9Q3xRHdrgA%40mail.gmail.com.

Re: Regression in Set-Cookie which affects Django users

On Sat, Aug 22, 2020 at 10:07 PM Adam Johnson  wrote:

> (The workaround is in this comment:
> https://github.com/django/django/pull/11894#issuecomment-577681440 , and
> if you want, a package: https://github.com/jotes/django-cookies-samesite )
>

Thank you. I was not aware of this package and middleware.

אורי.

-- 
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/CABD5YeGTtzHQMrsB%3Dc%3DHBeymNxWFJc1En9vqj%3DF1HEtO5P0odA%40mail.gmail.com.

Re: Regression in Set-Cookie which affects Django users

On Sat, Aug 22, 2020 at 9:48 PM Mariusz Felisiak 
wrote:

> We decided that it's a new feature that will not be backported to Django
> 3.0, see #30862 <https://code.djangoproject.com/ticket/30862>, and
> discussion in PR <https://github.com/django/django/pull/11894> (with few
> simple workarounds).
>

These decisions were probably before the breaking changes in Chrome.
https://www.chromestatus.com/feature/5088147346030592
https://www.chromium.org/updates/same-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/CABD5YeEB9FP_GivRDx0%2BC0dCV4rELhxU%2BEOxAVkuxstb2GhXMA%40mail.gmail.com.

Re: Regression in Set-Cookie which affects Django users

On Sat, Aug 22, 2020 at 9:34 PM Adam Johnson  wrote:

> Hi Uri
>
> You implied it, but to make it explicit - Django 3.1 allows setting the
> value "None" (string) for samesite cookies:
> https://docs.djangoproject.com/en/dev/releases/3.1/#django-contrib-sessions
> . Essentially you're asking for a backport of this feature.
>

Yes. But this may also affect other settings such as *CSRF_COOKIE_SAMESITE*.

You can also see this answer <https://stackoverflow.com/a/63539373/1412564>
on Stack Overflow.


>
> I think a backport is probably reasonable if sites are broken. You didn't
> write in your ticket in what way SameSite=Lax breaks your sites - can you
> explain the use cases you need SameSite=None for?
>

It is explained on Stack Overflow:
https://stackoverflow.com/questions/63538073/set-cookie-is-not-working-in-chrome-and-dolphin-with-two-websites

https://stackoverflow.com/questions/59298548/set-cookie-is-not-working-in-chrome-with-two-websites


אורי.

-- 
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/CABD5YeFN5wWwNcjszTxKFCTstXB1aSE8cM0UWeMTvP%3Dvt99sjg%40mail.gmail.com.

Regression in Set-Cookie which affects Django users

Django developers,

I just created issue #31933 <https://code.djangoproject.com/ticket/31933>:

It seems that there is a regression in *Set-Cookie* in browsers such as
Chrome and Dolphin, which affects Django users. *SESSION_COOKIE_SAMESITE =
None* does not work any more with those browsers. This affects all versions
of Django, and especially where it's not possible to explicitly set cookies
to *SameSite=None* (Django <= 3.0).

You can read about it in the following links:

Cookies default to SameSite=Lax
<https://www.chromestatus.com/feature/5088147346030592>
Reject insecure SameSite=None cookies
<https://www.chromestatus.com/feature/5633521622188032>

You can see more information in the question
<https://stackoverflow.com/q/63538073/1412564> I just asked on Stack
Overflow.

I think it should be made possible to explicitly set cookies to
*SameSite=None*, also in settings such as *SESSION_COOKIE_SAMESITE*, and
backport it to all working versions of Django.

אורי
u...@speedy.net

-- 
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/CABD5YeFnd0p5WmaLsePKzbeO_pR4xrZ5cE7%2BVgfhzHyjgB7uTw%40mail.gmail.com.

Re: Django default input validation accepts special caracters

2020-08-18 Thread אורי

On Tue, Aug 18, 2020 at 12:26 PM Adam Johnson  wrote:

>
> The only change we should be making is moving from separate first_name +
> last_name fields to solely a name field, since *many* people don't fit into
> that. I think there's a ticket, but there are massive backwards
> compatibility concerns.
>

This may be true - not all people have first_name & last_name or want to
use them online. But it's also convenient to be able to call a person by
their first name, and also allow them to use their full name on the
website. I checked popular websites - Facebook and Google require first
name and last name, Twitter, GitHub and Stack Overflow require only a
"name", and I heard that in some IP addresses and languages Facebook
doesn't require a last name, but I tried and I couldn't delete my last name
from Facebook. I have a formal last name, but I want to be registered only
with my first name on Facebook, which I can't. And by the way, Facebook,
Twitter and Github let me change my username, Google didn't. So I have to
use a username which doesn't reflect my real name on Google (I changed my
last name and the username reflects my former last name). The only way to
use a different username on Google is to create a new account. But also if
I change my username, my email address would change, and messages sent to
my previous email address might not reach me.

אורי.

-- 
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/CABD5YeE6wmedgQk5c15ND8TU4xN4iOMyS2Cn6cEL2NJ4DBi12A%40mail.gmail.com.

Re: The cotent types framework unreasonably limits model name length.

2020-08-10 Thread אורי

How can a class name be more than 100 characters? Can you give an example?

A limit of 100 characters seems reasonable to me, maybe even 60 would be
enough.

אורי
u...@speedy.net


On Tue, Aug 11, 2020 at 6:06 AM Richard Campen 
wrote:

> Hello
>
> I have hit what I feel is an arbitrary limit on the length of a django
> model class name. I am using the PostgreSQL backend, which smartly
> truncates table names above a certain size (normally 63 characters) which
> means in theory a table name can be of indeterminate length, as PostgreSQL
> will truncate it appropriately. However, if the model class name is greater
> than 100 characters than an error is thrown when saving the model name to
> the `django_content_type` model as the `ContentType.model` field uses a
> CharField with a limit of 100. This arbitrarily restricts the size of the
> model name when the db backend can handle it fine.
>
> I tried to go back in time to figure out if there was any context in
> setting the `ContentType.model` field max_length at 100 chars, but it was
> made before the Django project was migrated to git.
>
> I feel it would be best to switch this field to a TextField, as even 255
> characters seems an unreasonable limit to impose when the db backend can
> support longer names, though perhaps having a smaller (but configurable)
> max_length on the TextField would still be desirable.
>
> What are peoples feelings on this?
>
> Cheers,
> Richard
>
> --
> 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/26478a0a-5809-449f-b17d-d7223e2cfb3do%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/26478a0a-5809-449f-b17d-d7223e2cfb3do%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeFdA95UhJex%2BERf1pM-groRiUjO5tyLv300wSRjcWkGSQ%40mail.gmail.com.

Re: Django 4.0 sessions

2020-08-09 Thread אורי

Hi Tom,


On Sun, Aug 9, 2020 at 4:12 PM Tom Forbes  wrote:

> As a side note Uri, it’s good practice to keep your messages concise when
> posting. The very long first paragraph in your message containing 4 or 5
> questions is hard to parse and respond to, and not all of it appears
> relevant.
>
>
I apologize for the long post and paragraph.

אורי
u...@speedy.net

-- 
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/CABD5YeGYTqs1a_RARzCXF_Qkw-vqwu96tsgaKnAsHv%2B7SAfB8g%40mail.gmail.com.

Django 4.0 sessions

2020-08-09 Thread אורי

Django developers,

I'm using Django 3.0 with sessions on my websites, Speedy Net
<https://www.speedy.net/> and Speedy Match <https://www.speedymatch.com/>.
I understand that sessions as they are now (in Django 3.0) will be changed
and removed in Django 4.0. I would like to know how will it affect the
users of my websites? Will it log out any user who didn't visit the site
from Django 3.1 to Django 3.2, or will it also log out any user who didn't
login again to the website using Django 3.1 and 3.2? I use persistent
sessions and cookies for ~30 years, and I expect sessions to keep working
when I upgrade Django. I think I can handle logging out users who didn't
visit the site for ~16 months, but I can't handle users who visited the
site as authenticated users but didn't login again in more than ~16 months
- this will mean that when I upgrade (eventually) to Django 4.0, most of my
users will suddenly be logged out (who should be logged in). Is there a way
to overcome this? Are sessions objects created by the website other than
when users log in? This deprecation can cause me not to want to upgrade
Django to 4.0, which is a shame. I upgraded all versions of Django from 1.8
to 3.0, and I'm about to upgrade to 3.1 as well. I also had a problem when
I upgraded to Django 2.1, which affected my users, and there was a bug for
about 6 weeks on my website, because of introducing
*SESSION_COOKIE_SAMESITE* with the default 'Lax' in Django 2.1 [
https://stackoverflow.com/questions/59298548/set-cookie-is-not-working-in-chrome-with-two-websites].
Due to this bug my website didn't work properly for about 6 weeks. And I
don't want to cause more problems when I upgrade Django to 4.0. Actually I
would like the window to be wider - for example, log out users who didn't
visit the website for 2 or 3 years, and anyway convert their sessions
automatically without forcing them to login again (if they visited my
websites during this time). Will sessions be converted automatically or can
I cause them to be converted automatically to the new format and hashing
algorithm, while using Django 3.1 and 3.2, before I upgrade Django to 4.0?

By the way, both my websites are configured to log in and log out users
together - if they log in or log out from one website, they should be
automatically logged in or logged out from the other domain too.

Is it possible to change the sessions deprecation Django version so that
users will have about 2 or 3 years to convert their sessions?

Thanks,

אורי
(Uri)
u...@speedy.net

--
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/CABD5YeHY_%3DBaZyi0L%2Bp0tFmrJsFZp3V9n3JfR%3D925-440RnsRA%40mail.gmail.com.

Re: Status of 3.1 release blockers.

2020-08-06 Thread אורי

Thank you.

אורי
u...@speedy.net


On Fri, Aug 7, 2020 at 8:24 AM Mariusz Felisiak 
wrote:

>
> *> After I signed up and logged in, I reverted to Django 3.0, and then one
> user was logged out (who should be logged in) and another user got the
> exception `Incorrect padding` (from
> `base64.b64decode(session_data.encode('ascii'))`). *
>
> This is a separate issue, see #31864
> <https://code.djangoproject.com/ticket/31864>.
>
> --
> 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/d220613e-e717-4518-b204-14d5c2b2ac47n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/d220613e-e717-4518-b204-14d5c2b2ac47n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeFR9g5CHJCyU8Y88e85ueNEQBLdzrGPP75ewa%2BJxG5Ykw%40mail.gmail.com.

Re: Status of 3.1 release blockers.

2020-08-05 Thread אורי

Hi,

Have you tested multiple servers with Django versions 3.0 and 3.1 with
`DEFAULT_HASHING_ALGORITHM = 'sha1'`? I created a branch with this setting,
with Django 3.1, and then I used it on our staging server. After I signed
up and logged in, I reverted to Django 3.0, and then one user was logged
out (who should be logged in) and another user got the exception `Incorrect
padding` (from `base64.b64decode(session_data.encode('ascii'))`). It looks
like the setting I created  `DEFAULT_HASHING_ALGORITHM = 'sha1'` is ignored
with Django 3.1. I know you don't support downgrading Django, but this
might also affect users who run several servers in parallel, with Django
3.0 and 3.1.

When I downgraded I rolled back 2 migrations - one I created myself
(match_accounts.0008_auto_20200804_1453) and
(auth.0012_alter_user_first_name_max_length). But rolling back these
migrations looks like it's not related to this issue.

אורי
u...@speedy.net

On Mon, Aug 3, 2020 at 11:25 AM Mariusz Felisiak 
wrote:

> Hi Markus,
>
> I don't see a clear path to do this, we cannot add a setting that
> accepts a string and immediately (in the next release) change it to a list,
> this will require a deprecation path etc. and will be really confusing to
> users. IMO we can reconsider this new feature in the next release with a
> different setting.
>
> 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/77dfa750-21c2-42ef-a69c-077217746098n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/77dfa750-21c2-42ef-a69c-077217746098n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeF3p33QuL6104BLWttLenfoscdcmLZwEUBod78ORE5HdQ%40mail.gmail.com.

Re: Status of 3.1 release blockers.

I also think, when the old hashing algorithm is deprecated, it's better to
convert sessions to the new hashing algorithm without logging out users and
without raising errors or exceptions. Is it possible? And notice that the
Django user may change this setting only in the future, such as in Django
4.0 and even later. What will happen then?
אורי
u...@speedy.net


On Fri, Jul 31, 2020 at 11:46 PM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:

> I've created a draft PR13262 <https://github.com/django/django/pull/13262>
> with the new setting for the default hashing algorithm.
>
> --
> 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/c3b3025f-3830-464a-8c8c-883ec606720an%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c3b3025f-3830-464a-8c8c-883ec606720an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeFwrijwMt81ijbBw2TST-phxBSTW%2BSF7iv4SneBa2oZHg%40mail.gmail.com.

Re: Status of 3.1 release blockers.

Hi Mariusz,

How do you propose running several versions of Django 3.0 and 3.1 with this
PR and setting? Does it have to be defined, or is it enough using the
default setting? And when upgrading Django to 3.1, what is the default
setting if this setting is not explicitly defined? And how will it affect
sessions in case of downgrading back to 3.0? Will it be possible to
downgrade also with the default setting?

Also, maybe it's better to document the answers to these questions in the
release notes and in the definition of the new setting. And also, how to
define this setting to its default value in Django versions <= 3.0. What do
you think?

אורי
u...@speedy.net

On Fri, Jul 31, 2020 at 11:46 PM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:

> I've created a draft PR13262 <https://github.com/django/django/pull/13262>
> with the new setting for the default hashing algorithm.
>
> --
> 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/c3b3025f-3830-464a-8c8c-883ec606720an%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c3b3025f-3830-464a-8c8c-883ec606720an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeG1KNTg9YGfUqxTmV82qU1Khs_E-EwfUyR-OHcaornzZA%40mail.gmail.com.

Re: Status of 3.1 release blockers.

Hi Carlton,

I think a possible solution can be if Django 3.0 will be patched to handle
sessions created by 3.1. This will allow both downgrading Django and
running Django on several servers with 3.0 and 3.1 in parallel. If this is
too late now to do it before releasing 3.1, maybe you can postpone this
change (of hashing algorithm, if I understand correctly) to Django 3.2. And
then of course, patch 3.0 and 3.1 to handle sessions created by 3.2.

אורי
u...@speedy.net


On Fri, Jul 31, 2020 at 2:13 PM Carlton Gibson 
wrote:

> Hi Uri.
>
> On 31 Jul 2020, at 12:11, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
>
> On Fri, Jul 31, 2020 at 12:28 PM Mariusz Felisiak <
> felisiak.mari...@gmail.com> wrote:
>
>> Markus reported a release blocker #31842
>> <https://code.djangoproject.com/ticket/31842>related with running an app
>> on multiple servers with different versions of Django (3.0.x or 3.1).
>>
>
> I think it might be related to an issue I reported - #31592
> <https://code.djangoproject.com/ticket/31592>. Django 3.0 can't handle
> sessions created by Django 3.1.
>
>
> Yes, it’s related. Your issue was downgrading IIRC. This is “can’t upgrade
> piecemeal” — but a solution may allow your use-case too.
>
> C.
>
> --
> 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/AEC8D4F2-E042-4A6B-9E9D-7D0584BB42B4%40gmail.com
> <https://groups.google.com/d/msgid/django-developers/AEC8D4F2-E042-4A6B-9E9D-7D0584BB42B4%40gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CABD5YeEVhj2T0Yq0q%3DESvKjEHfXddiTNtgo_M%2B%2BxDvSKs5xRYw%40mail.gmail.com.

Re: Status of 3.1 release blockers.