Re: A more useful list of common passwords?

2018-03-29 Thread Curtis Maloney

By which I mean... hi Brenton! Great to see you being active again :)

It's great you've taken the time to do this, and the benefits are very 
clear [improved security], but what are the costs?


Whilst you're at it, what is the new file size?

--
Curtis



On 03/30/2018 04:26 PM, Curtis Maloney wrote:

What sort of performance impact is this having over the existing list?

What's the additional memory load, if any?

--
Curtis


On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
Three years ago Django introduced the CommonPasswordValidator and 
included a list of 1,000 passwords considered to be "common". That 
list was based on leaked passwords and came from xato.net[1].


I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 
20,000 of which are available in a gist from Royce Williams[3], 
including the frequency, md5 hash and plain text password.


Interestingly there's 27 passwords in the Django list that aren't in 
the HIBP list. I'd post them here but they're mostly short and not 
safe for work.


I've created a ticket for the increase in size[4] but wanted to check 
in and make sure this is something django-developers thinks is valuable.


Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25 


[2]: https://haveibeenpwned.com/Passwords
[3]: 
https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7

[4]: https://code.djangoproject.com/ticket/29274

--
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/0a215878-9d3f-4446-a018-602694f54904%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/2cb005ec-5f22-a77e-ddeb-791ab85ff03c%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: A more useful list of common passwords?

2018-03-29 Thread Curtis Maloney

What sort of performance impact is this having over the existing list?

What's the additional memory load, if any?

--
Curtis


On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
Three years ago Django introduced the CommonPasswordValidator and 
included a list of 1,000 passwords considered to be "common". That list 
was based on leaked passwords and came from xato.net[1].


I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 20,000 
of which are available in a gist from Royce Williams[3], including the 
frequency, md5 hash and plain text password.


Interestingly there's 27 passwords in the Django list that aren't in the 
HIBP list. I'd post them here but they're mostly short and not safe for 
work.


I've created a ticket for the increase in size[4] but wanted to check in 
and make sure this is something django-developers thinks is valuable.


Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25

[2]: https://haveibeenpwned.com/Passwords
[3]: https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7
[4]: https://code.djangoproject.com/ticket/29274

--
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/0a215878-9d3f-4446-a018-602694f54904%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/5565c4fd-5de3-dc52-c952-5ad4b555bac0%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


A more useful list of common passwords?

2018-03-29 Thread Brenton Cleeland
Three years ago Django introduced the CommonPasswordValidator and included 
a list of 1,000 passwords considered to be "common". That list was based on 
leaked passwords and came from xato.net[1].

I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 20,000 of 
which are available in a gist from Royce Williams[3], including the 
frequency, md5 hash and plain text password.

Interestingly there's 27 passwords in the Django list that aren't in the 
HIBP list. I'd post them here but they're mostly short and not safe for 
work.

I've created a ticket for the increase in size[4] but wanted to check in 
and make sure this is something django-developers thinks is valuable.

Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25
[2]: https://haveibeenpwned.com/Passwords
[3]: https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7
[4]: https://code.djangoproject.com/ticket/29274

-- 
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/0a215878-9d3f-4446-a018-602694f54904%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

2018-03-29 Thread Andrew Standley
Thank you all for the replies.

@Josh Smeaton 
Essentially yes; specifically I was wondering whether I was failing to 
consider behaviour that couldn't be modeled via a Q object, since as you 
mention the current 
https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relationships
 documentation 
uses AND vs OR to justify the behaviour.

@Marten Kenbeek
Got it. Thank you sincerely for the example. I feel a bit foolish now it's 
clicked as I realize the documentation says nearly the same thing, but for 
some reason even after reading through the spanning multi-valued 
relationship documentation multiple times I was completely missing the 
point. 

So would I be correct in stating that all the reported weirdness with 
objects appearing multiple times in QuerySets is mostly a side effect of 
implementing the AND condition on *any* related objects?  

-- 
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/95015709-2809-4895-97e6-21d02b49f803%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

2018-03-29 Thread Marten Kenbeek
These queries are actually not equivalent. Consider the following code:

>>> r = Related.objects.create(field='related')
>>> r.main_set.create(field_one='1', field_two='3')

>>> r.main_set.create(field_one='2', field_two='4')

>>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))
]>
>>> Related.objects.filter(main__field_two='2').filter(main__field_one='1')


Here the first queryset matches the Related instance, because it satisfies 
Q(main__field_one='1'), so one of the OR conditions is satisfied. The 
second queryset doesn't match the Related instance because 
.filter(main__field_two='2') is not true. Further filters can only reduce 
the data returned by the queryset. 

The difference between one or two filter calls is more subtle. Consider the 
following queries:

>>> Related.objects.filter(main__field_one='1').filter(main__field_two='4')
]>
>>> Related.objects.filter(main__field_one='1', main__field_two='4')


Here the first query returns the Related instance because it has a related 
Main instance with field_one='1', and it has a (different) related Main 
instance with field_two='4'. Thus it satisfies both conditions, and the AND 
condition is fulfilled. These can be different objects because of the two 
joins, but both conditions still need to be satisfied. The second query 
does not return the Related instance, because it does not have a single 
related Main instance that has both field_one='1' and field_two='4'. In 
this case there's only a single join, so the same Main instance has to 
satisfy both conditions.

On Thursday, March 29, 2018 at 11:26:44 PM UTC+2, Andrew Standley wrote:
>
> I have recently become acquainted with some ORM behaviour for reverse 
> relationships that "makes no sense", and I'm hoping someone can explain the 
> justification for the current behaviour. 
>
> This specifically relates to `filter` behaviour referenced in 29271 
> , and 16554 
>  which seems tangentially 
> related to several issues with `exclude` (24421 
> , 14645 
> , 17315 
> ) and aggregate expressions (
> 16603 , 19415 
> )
>
> Most of the confusion about 'intended' behaviour and confirmed 'bugged' 
> behaviour seems to relate to the ORM's use of joins for reverse 
> relationships.
> I think my personal confusion boils down to two questions.
>
> 1) Is there some fundamental limitation in the ORM that prevents reducing 
> the number of joins? Several of these tickets indicate how the ORM could 
> potentially produce similar results with queries that did not use multiple 
> joins. Why is that not desirable behaviour?
>
> 2) Why is the current behaviour of `filter` for multi-value relationships 
> 'intended'? I'm hoping I am missing something obvious but it seems to me 
> that `Q` objects would support the type of behaviour suggested in the 
> spanning 
> multi-valued relationships 
> 
>  documentation 
> in a much more inituative manner. In a test case with models
>
> class Related(models.Model):
> field = models.CharField(max_length=100)
>
> class Main(models.Model):
> field_one = models.CharField(max_length=100)
> field_two = models.CharField(max_length=100)
> related = models.ForeignKey(Related, on_delete=models.CASCADE)
>
>
> both
>
> >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM 
> "test_app_related" INNER JOIN "test_app_main" ON ("test_app_related"."id"=
>  "test_app_main"."related_id") WHERE ("test_app_main"."field_two" = "2"
>  OR "test_app_main"."field_one" = "1")
>
> and
>
> >>> Related.objects.filter(main__field_two='2').filter(main__field_one='1'
> )
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM "test_app_
> related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= 
> "test_app_main"."related_id") INNER JOIN "test_app_main" T3 ON ("test_app_
> related"."id" = T3."related_id") WHERE ("test_app_main"."field_two" = 
> "two" AND T3."field_one" = "one")
>
> Produce exactly the same results but the second seems to have an 
> unnecessary extra join, and directly contradicts the behaviour of filter 
> with non multi-valued fields.
>
>
>
> In short, could someone be kind enough to explain the justification for 
> all this weird behaviour with multi-value relationships?
>
>
> Cheers,
>   Andrew
>

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

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

2018-03-29 Thread Josh Smeaton
It sounds like you understand what the current behaviour is, and you think 
that it would be better modelled with Q objects, is that the case? I can 
see where you're coming from, as even the docs explain the difference 
loosely in terms of AND and OR.

Q(entry__headline__contains='Lennon') & Q(entry__pubdate__year=2008) would 
be the filter(cond_a, cond_b).
Q(entry__headline__contains='Lennon') | Q(entry__pubdate__year=2008) would 
be the filter(cond_a).filter(cond_b).

The justification for **not** doing it this way, I suppose, would be that Q 
objects may not have existed at the time, or this was just never 
considered. The justification for not changing it to be this way now would 
be because it'd break user code everywhere.

I agree that the Q &/| logic would be more intuitive, but it's not 
something we can change at this point.

On Friday, 30 March 2018 08:26:44 UTC+11, Andrew Standley wrote:
>
> I have recently become acquainted with some ORM behaviour for reverse 
> relationships that "makes no sense", and I'm hoping someone can explain the 
> justification for the current behaviour. 
>
> This specifically relates to `filter` behaviour referenced in 29271 
> , and 16554 
>  which seems tangentially 
> related to several issues with `exclude` (24421 
> , 14645 
> , 17315 
> ) and aggregate expressions (
> 16603 , 19415 
> )
>
> Most of the confusion about 'intended' behaviour and confirmed 'bugged' 
> behaviour seems to relate to the ORM's use of joins for reverse 
> relationships.
> I think my personal confusion boils down to two questions.
>
> 1) Is there some fundamental limitation in the ORM that prevents reducing 
> the number of joins? Several of these tickets indicate how the ORM could 
> potentially produce similar results with queries that did not use multiple 
> joins. Why is that not desirable behaviour?
>
> 2) Why is the current behaviour of `filter` for multi-value relationships 
> 'intended'? I'm hoping I am missing something obvious but it seems to me 
> that `Q` objects would support the type of behaviour suggested in the 
> spanning 
> multi-valued relationships 
> 
>  documentation 
> in a much more inituative manner. In a test case with models
>
> class Related(models.Model):
> field = models.CharField(max_length=100)
>
> class Main(models.Model):
> field_one = models.CharField(max_length=100)
> field_two = models.CharField(max_length=100)
> related = models.ForeignKey(Related, on_delete=models.CASCADE)
>
>
> both
>
> >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM 
> "test_app_related" INNER JOIN "test_app_main" ON ("test_app_related"."id"=
>  "test_app_main"."related_id") WHERE ("test_app_main"."field_two" = "2"
>  OR "test_app_main"."field_one" = "1")
>
> and
>
> >>> Related.objects.filter(main__field_two='2').filter(main__field_one='1'
> )
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM "test_app_
> related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= 
> "test_app_main"."related_id") INNER JOIN "test_app_main" T3 ON ("test_app_
> related"."id" = T3."related_id") WHERE ("test_app_main"."field_two" = 
> "two" AND T3."field_one" = "one")
>
> Produce exactly the same results but the second seems to have an 
> unnecessary extra join, and directly contradicts the behaviour of filter 
> with non multi-valued fields.
>
>
>
> In short, could someone be kind enough to explain the justification for 
> all this weird behaviour with multi-value relationships?
>
>
> Cheers,
>   Andrew
>

-- 
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/81339adc-875e-48ac-a41f-4e45d0c26823%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

2018-03-29 Thread Curtis Maloney

On 03/30/2018 08:57 AM, Ryan Hiebert wrote:
It's a subtle difference between how a single filter works and two 
filters work together over to-many relationships. Here's a writeup that 
I found helpful: 
https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/


It's also addressed in the documentation:

https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relationships

--
Curtis

--
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/f31f5413-59e8-eec2-7adb-e619bf5637cb%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

2018-03-29 Thread Ryan Hiebert
It's a subtle difference between how a single filter works and two filters
work together over to-many relationships. Here's a writeup that I found
helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/

On Thu, Mar 29, 2018 at 4:26 PM, Andrew Standley 
wrote:

> I have recently become acquainted with some ORM behaviour for reverse
> relationships that "makes no sense", and I'm hoping someone can explain the
> justification for the current behaviour.
>
> This specifically relates to `filter` behaviour referenced in 29271
> , and 16554
>  which seems tangentially
> related to several issues with `exclude` (24421
> , 14645
> , 17315
> ) and aggregate expressions (
> 16603 , 19415
> )
>
> Most of the confusion about 'intended' behaviour and confirmed 'bugged'
> behaviour seems to relate to the ORM's use of joins for reverse
> relationships.
> I think my personal confusion boils down to two questions.
>
> 1) Is there some fundamental limitation in the ORM that prevents reducing
> the number of joins? Several of these tickets indicate how the ORM could
> potentially produce similar results with queries that did not use multiple
> joins. Why is that not desirable behaviour?
>
> 2) Why is the current behaviour of `filter` for multi-value relationships
> 'intended'? I'm hoping I am missing something obvious but it seems to me
> that `Q` objects would support the type of behaviour suggested in the spanning
> multi-valued relationships
> 
>  documentation
> in a much more inituative manner. In a test case with models
>
> class Related(models.Model):
> field = models.CharField(max_length=100)
>
> class Main(models.Model):
> field_one = models.CharField(max_length=100)
> field_two = models.CharField(max_length=100)
> related = models.ForeignKey(Related, on_delete=models.CASCADE)
>
>
> both
>
> >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM
> "test_app_related" INNER JOIN "test_app_main" ON ("test_app_related"."id"=
>  "test_app_main"."related_id") WHERE ("test_app_main"."field_two" = "2"
>  OR "test_app_main"."field_one" = "1")
>
> and
>
> >>> Related.objects.filter(main__field_two='2').filter(main__field_one='1'
> )
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM "test_app_
> related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= "test_
> app_main"."related_id") INNER JOIN "test_app_main" T3 ON ("test_app_
> related"."id" = T3."related_id") WHERE ("test_app_main"."field_two" =
> "two" AND T3."field_one" = "one")
>
> Produce exactly the same results but the second seems to have an
> unnecessary extra join, and directly contradicts the behaviour of filter
> with non multi-valued fields.
>
>
>
> In short, could someone be kind enough to explain the justification for
> all this weird behaviour with multi-value relationships?
>
>
> Cheers,
>   Andrew
>
> --
> 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/22234c13-3152-473f-86bd-
> 04b41efd9203%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/CABpHFHQBTdZ%3DVSeDa1APVZUTpoT7cFhgRFxxVgY4cVtnS4GYvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Django ORM Handling of Reverse Relationships and Multi-Value Relationships

2018-03-29 Thread Andrew Standley
I have recently become acquainted with some ORM behaviour for reverse 
relationships that "makes no sense", and I'm hoping someone can explain the 
justification for the current behaviour. 

This specifically relates to `filter` behaviour referenced in 29271 
, and 16554 
 which seems tangentially 
related to several issues with `exclude` (24421 
, 14645 
, 17315 
) and aggregate expressions (
16603 , 19415 
)

Most of the confusion about 'intended' behaviour and confirmed 'bugged' 
behaviour seems to relate to the ORM's use of joins for reverse 
relationships.
I think my personal confusion boils down to two questions.

1) Is there some fundamental limitation in the ORM that prevents reducing 
the number of joins? Several of these tickets indicate how the ORM could 
potentially produce similar results with queries that did not use multiple 
joins. Why is that not desirable behaviour?

2) Why is the current behaviour of `filter` for multi-value relationships 
'intended'? I'm hoping I am missing something obvious but it seems to me 
that `Q` objects would support the type of behaviour suggested in the spanning 
multi-valued relationships 

 documentation 
in a much more inituative manner. In a test case with models

class Related(models.Model):
field = models.CharField(max_length=100)

class Main(models.Model):
field_one = models.CharField(max_length=100)
field_two = models.CharField(max_length=100)
related = models.ForeignKey(Related, on_delete=models.CASCADE)


both

>>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))

SQL:
SELECT "test_app_related"."id", "test_app_related"."field" FROM 
"test_app_related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= 
"test_app_main"."related_id") WHERE ("test_app_main"."field_two" = "2" OR 
"test_app_main"."field_one" = "1")

and

>>> Related.objects.filter(main__field_two='2').filter(main__field_one='1')

SQL:
SELECT "test_app_related"."id", "test_app_related"."field" FROM "test_app_
related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= "test_app_
main"."related_id") INNER JOIN "test_app_main" T3 ON ("test_app_related".
"id" = T3."related_id") WHERE ("test_app_main"."field_two" = "two" AND T3.
"field_one" = "one")

Produce exactly the same results but the second seems to have an 
unnecessary extra join, and directly contradicts the behaviour of filter 
with non multi-valued fields.



In short, could someone be kind enough to explain the justification for all 
this weird behaviour with multi-value relationships?


Cheers,
  Andrew

-- 
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/22234c13-3152-473f-86bd-04b41efd9203%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: default values on database level

2018-03-29 Thread Michael Grijalva
Yeah seems like `db_default` was the felling, at least last time I scanned 
through this long-going discussion :D 

I've had to tweak Django's migration handling a bit to handle our 
zero-downtime requirements.

SQLalchemy has had this for awhile 
(http://docs.sqlalchemy.org/en/latest/core/defaults.html#server-side-defaults), 
so I see no reason why it can't be done in Django.

On Thursday, March 29, 2018 at 9:12:24 AM UTC-7, Paul Tiplady wrote:
>
> Closing the loop here -- Tim just reopened 
> https://code.djangoproject.com/ticket/470.
>
> This feature would also be useful for achieving zero-downtime migrations, 
> as discussed in https://code.djangoproject.com/ticket/29266.
>
> Sounds like the design has mostly been agreed -- would a PR be accepted 
> that just implements the simple `db_default` field without attempting 
> PostgreSQL RETURNING or database functions (CURRENT_TIMESTAMP), and just 
> provides static defaults?
>
> Cheers,
> Paul
>
> On Monday, April 4, 2016 at 2:08:39 AM UTC-7, Shai Berger wrote:
>>
>> Hi everybody, 
>>
>> Waking this up again because, going over some older stuff, I found a 
>> ticket 
>> asking for this feature: 
>>
>> https://code.djangoproject.com/ticket/470 
>>
>> It was closed wontfix, but if anybody likes to put a 3-digit-numbered 
>> Django 
>> bug under their belt, it's there. The discussion in this thread would 
>> indicate 
>> that it should be re-opened. 
>>
>> Shai. 
>>
>

-- 
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/36b8377d-d17e-4ce9-9520-245ad8cca338%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: default values on database level

2018-03-29 Thread Paul Tiplady
Closing the loop here -- Tim just 
reopened https://code.djangoproject.com/ticket/470.

This feature would also be useful for achieving zero-downtime migrations, 
as discussed in https://code.djangoproject.com/ticket/29266.

Sounds like the design has mostly been agreed -- would a PR be accepted 
that just implements the simple `db_default` field without attempting 
PostgreSQL RETURNING or database functions (CURRENT_TIMESTAMP), and just 
provides static defaults?

Cheers,
Paul

On Monday, April 4, 2016 at 2:08:39 AM UTC-7, Shai Berger wrote:
>
> Hi everybody, 
>
> Waking this up again because, going over some older stuff, I found a 
> ticket 
> asking for this feature: 
>
> https://code.djangoproject.com/ticket/470 
>
> It was closed wontfix, but if anybody likes to put a 3-digit-numbered 
> Django 
> bug under their belt, it's there. The discussion in this thread would 
> indicate 
> that it should be re-opened. 
>
> Shai. 
>

-- 
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/0918d753-2d98-4731-8180-922cc8e1d1d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: adding object level permissions on the core permissions

2018-03-29 Thread Jani Tiainen
Hi.

To achieve object level permissions you need to write custom authentication
backend.

Django does provide support for object level permissions but there isn't
default implementation because object level permissions have different
meaning for different people.

See auth docs for more information.

to 29. maaliskuuta 2018 klo 17.37 Erick Lestrange mr-programs.com <
livingandwast...@gmail.com> kirjoitti:

> I want to add object level permissions to the Django'd core auth app
> Permission model.
>
> currently permission instances follow this string format
> '._' ideally i want this object level permissions to
> follow a similar string format with as few variations from the originals as
> possible
>
> but the main thing this permissions should do is being automatically
> loaded by the template system just as current ones in order to avoid db
> queries. this is a must!
>
> --
> 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/9651514e-60dc-4bd5-a33e-64b6d36481b2%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/CAHn91odL6C2V-v_t4Qjo%2BXTwLztm6PNgLZDF6TGSwRZpELshYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


adding object level permissions on the core permissions

2018-03-29 Thread Erick Lestrange mr-programs.com
I want to add object level permissions to the Django'd core auth app Permission 
model.

currently permission instances follow this string format 
'._' ideally i want this object level permissions to 
follow a similar string format with as few variations from the originals as 
possible

but the main thing this permissions should do is being automatically loaded by 
the template system just as current ones in order to avoid db queries. this is 
a must!

-- 
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/9651514e-60dc-4bd5-a33e-64b6d36481b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Feature Request: Better media management

2018-03-29 Thread Mario Colombo
Recently, other CMS projects have made quantum leaps in regards to media 
management. Our clients often feel that djangocms is a bit on the lean side 
in regards to working with media (images).

One of our clients suggested, for example, to have bigger image thumbnails 
in the djangocms folder / media admin interface, which in our opinion would 
be a step into the right direction. I am aware that this is something we 
would have to take up with the https://github.com/divio/cmsplugin-filer 
project.

This is more to start the discussion around media management as part of a 
CMS. Please let me know.

All the best

Mario


-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/99c597c5-f10b-4661-80f0-3c346908ac0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.