Re: Replacing the contrib.sites Site model with a setting?

[Anssi Kääriäinen]

Could we make the sites portion of Django an interface? In settings you 
give something like SITES_PROVIDER = 'myapp.sites.MultiTenancySite', and 
that provider then needs to fulfill a given API. This way we wouldn't need 
to offer anything complex in-built, but users would be free to do whatever 
they want to.

 - Anssi

On Saturday, January 30, 2016 at 11:11:08 AM UTC+2, Aymeric Augustin wrote:
>
> This is a valid use case, but not one django.contrib.sites (officially) 
> supports, since it requires a constant SITE_ID setting. 
>
> While Tim's suggestion doesn't cause a regression, it doesn't make this 
> pattern easier to implement either. 
>
> It's definitely worth considering. 
>
> -- 
> Aymeric. 
>
> > Le 30 janv. 2016 à 08:01, Max Arnold  a 
> écrit : 
> > 
> > What if this list of sites needs to be changed dynamically without app 
> restart (multitenancy)? 
> > 
> >> On Fri, Jan 29, 2016 at 12:45:02PM -0800, Tim Graham wrote: 
> >> In another thread about adding a "scheme" field to the Site model [1], 
> I 
> >> floated the idea of moving the data stored by the Site model into a 
> setting: 
> >> 
> >> I've sometimes thought that the Site model violates the principle that 
> you 
> >> shouldn't put configuration in your database. I guess there's some 
> >> usefulness to having a ForeignKey to the site, but... would it be 
> feasible 
> >> to offer a SITES setting that could be used instead? e.g. 
> >> 
> >> SITES = { 
> >>1: {'scheme': 'http', 'domain': example.com, 'name': 'My 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20160130070141.GA2770%40otg.dm.
>  
>
> > 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/2014647b-aa3d-412f-8fc3-a0bc646e9a4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Review Request] Added support for database delegated fields (like AutoField)

[Anssi Kääriäinen]

The options for save() API seem to be:
  1. refresh_fields=[...] for save() - if set, then issue RETURNING for 
fields mentioned in the refresh_fields API.
  2. expressions: my_model.updated_at = TransactionNow(); my_model.save(), 
where TransactionNow is flagged to refresh the value from DB post-save.
  3. field flags like done in the PR.

Field flags are nice for things you always want to load from database (say, 
updated_at).

If the use cases we target are "generate value in db on insert" and 
"generate value in db on insert or update", and only those, then I think we 
can go with just a flag that tells Django to always skip the model's value 
on save(), and to reload from DB always. 

We are going to override the assigned value on save(), but I think it has 
to be this way. Consider:
  a_object.save()  # a_object.updated_at is set to '2016-02-03' as it is 
database delegated
  a_object.save()  # a_object.updated_at has a value, so we should error if 
we don't ignore the value
forcing users to set the value to None pre-save breaks the whole field flag 
feature. We could go directly with expressions in that case. We could also 
use the value in the update and require the DB trigger to ignore the value.

We don't have a separate flag for doing the refresh on insert only, but 
that isn't IMO such a big problem. We are going to add a minor overhead to 
updating by refreshing a field value from the DB when it hasn't changed, 
but making the API simpler is worth this IMO.

So, my opinion is that for the field flags API we need just one flag. A 
name like db_generated comes to mind. This gives a nice way to support the 
most common use case - that of calculating an inserted_at/updated_at field 
directly in DB.

After we have the field flag API, I think we should aim for expressions 
support. For expressions we should have enough flags for allowing full 
control over save() behavior. So, if the db_generated field flag isn't 
enough for some use case, you can go low-level and use expressions 
directly. We could perhaps even allow db_generated value to be an 
expression - if so, that expression would be used on save() and 
bulk_create().

For the update_fields change, I think we can do that completely separately. 
The same goes for changing the way how deferred fields are implemented.

 - Anssi

-- 
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/dedc791d-232d-4c93-9716-687963ca5272%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #10686 - inheritance of extra permissions from base class to child class

[Sergei Maertens]

Thanks for the input, that clears up some details which bring me on
agreement for the first suggestion.
Op 2 feb. 2016 21:51 schreef "Shai Berger" :

> Hi Sergei,
>
> Two notes:
>
> 1) For Abstract base classes, Meta is inherited by default[1] which would
> make
> the permissions inherited by default. For multi-table inheritance, this is
> not
> the case[2].
>
> 2) The second option as you presented it, where AssignedTask.Meta's
> permissions are added to its parent's permissions, rather than replacing
> them,
> appears unpythonic to me. Python, consistently, requires such accumulation
> in
> inheritence to be explicit.
>
> So, I think I would go with Tim's first suggestion. It means that, if
> BaseTask
> is concrete, then, indeed, its subclasses might need some boilerplate. Note
> that such boilerplate may be reduced  by other means -- e.g. defining a
> base-
> class for all the Meta's as an independent, non-nested class. At least in
> principle, you could even give this base-Meta a metaclass that will
> implement
> the unpythonic accumulating-instead-of-overriding inheritence; but I don't
> think Django should do something like that.
>
> HTH,
> Shai.
>
> [1]
> https://docs.djangoproject.com/en/1.9/topics/db/models/#meta-inheritance
> [2]
> https://docs.djangoproject.com/en/1.9/topics/db/models/#meta-and-multi-
> table-inheritance
>
> On Tuesday 02 February 2016 15:52:19 Sergei Maertens wrote:
> > Hi all,
> >
> > I was browsing tickets and stumbled
> > upon https://code.djangoproject.com/ticket/10686, which was accepted
> except
> > for lack of documentation. The patch in the mentioned ticket makes it so
> > that a Model class that's used as base class with extra permissions:
> >
> > class BaseTask(models.Model):
> > ...
> > class Meta:
> >permissions = (
> >('view_%(class)s', 'Can view %(class)s'),
> >)
> >
> > will make those permissions specific for any child classes:
> >
> > class TodoTask(BaseTask):
> > pass
> >
> >
> > class AssignedTask(BaseTask):
> > assignee = models.ForeignKey(settings.AUTH_USER_MODEL)
> >
> > class Meta:
> > permissions = (
> > ('reassign_assignedtask', 'Can reassign assigned task')
> > )
> >
> >
> >
> >
> > With the current patch, TodoTask would have one extra permission:
> > view_todotask, and AssignedTask would have two: view_assignedtask and
> > reassign_assignedtask.
> >
> > Now there were some concerns on the pull request, and input is needed:
> >
> >
> >- in its current state, Django will not inherit the base class
> >permissions, so AssignedTask would end up only with the
> >reassign_assignedtask permission (so missing view_assignedtask). The
> > patch ensures that inheritance is applied, and adds an extra Meta option:
> > inherit_permissions. Setting that to False yields the current behaviour -
> > no base class permissions are inherited. Disadvantages of this approach:
> -
> > yet another Meta attribute
> >   - more tight coupling between Meta and django.contrib.permissions
> >   (pointed out by Tim Graham)
> >   - 'hidden' second feature within the initial enhancee
> >
> > Two alternatives to avoid having to add inherit_permisisons have been
> > proposed by Tim:
> >
> > class AssignedTask(BaseTask):
> > assignee = models.ForeignKey(settings.AUTH_USER_MODEL)
> >
> > class Meta:
> > permissions = BaseTask.Meta.permissions + (
> > ('reassign_assignedtask', 'Can reassign assigned task')
> > )
> >
> > It looks like the inheritance of permissions would not be a default then,
> > which would require the other model to be changed to:
> >
> > class TodoTask(BaseTask):
> > class Meta:
> > permissions = BaseTask.Meta.permissions
> >
> >
> > In my opinition this introduces boilerplate which you get for free if the
> > permissions are inherited by default. On the upside, it is more explicit.
> >
> > Another suggestion was to use good old fashioned Python inheritance:
> >
> > class TodoTask(BaseTask):
> > class Meta(BaseTask.Meta):
> >pass
> >
> >
> > class AssignedTask(BaseTask):
> > assignee = models.ForeignKey(settings.AUTH_USER_MODEL)
> >
> > class Meta(BaseTask.Meta):
> > permissions = (
> > ('reassign_assignedtask', 'Can reassign assigned task')
> > )
> >
> >
> > The latter two suggestions would ofcourse require fixing the patch, but
> > that's an implementation detail.
> >
> > Input would be greatly valued.
>

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

Re: Remove null assingment check for non-nullable fields?

[Anssi Kääriäinen]

On Wednesday, February 3, 2016 at 1:26:26 AM UTC+2, Tim Graham wrote:
>
> There's a proposal to remove this behavior:
>
>
> >>> obj.fk = None
> ValueError('Cannot assign None: "Obj.fk" does not allow null values.)
>

I don't see this check as necessary - if you try to save such an object you 
will get an error. If you don't, then there is no harm done.

 - Anssi

-- 
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/e11ba330-bdcb-4083-b790-dbf57b4d38aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26165 new Cleanup/optimization wanted to start with a documentation ticket

[Vivek unni]

Thanks. I was going to add the questions at the end of the csrf.txt. Thanks for 
the help. I have claimed the ticket. I will send a pull request in a day or 
two. 

-- 
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/abcc513c-096e-4415-846e-8c56a71b61c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Admin Improvement - Autocomplete & improved search for FKs

[Cristiano Coelho]

Hello,

On one of my projects I'm using django-grappelli to improve the admin site 
( https://github.com/sehmaschine/django-grappelli ) which was used before 
the very nice face wash the admin interface received on 1.9. So right now 
if I were to update to 1.9, the only thing I would use from this library 
would be the autocomplete and improved search features for foreign key 
models (includes inlines as well) and some other very minor features since 
the 1.9 interface is quite nicer.

What's Autocomplete like? Basically, rather than a standard dropdown for 
foreign keys, you have a textfield where you can search and it then 
populate, the library implements it adding an additional required static 
method to models so you indicate which fields should be searched through 
(however in my opinion that should actually go into the ModelAdmin 
definition) and then jqueryui autocomplete and some other javascript plus 
required urls for this. I think anyone around knows how an auto complete 
works.

Then for the improved search, which is a second option (you may use one, 
both or none), the library adds a small search button next to the dropdown 
(or textbox) which will open in a pop up (I actually don't like it being a 
pop up at all) which simply contains the actual list page for that model 
(the one from the FK dropdown/textbox) having all the advantages of the 
features you implemented for that model (ie searching, filtering, sorting, 
etc)
I have attached some screenshots of these two to help understand it.

There are other minor feature that are nice also, like the ability to 
collapse inline models, or to use dropdowns for the filtering on the right 
rather than displaying all values (which makes it really bad for big 
tables).

So these two features are quite nice, but installing a complete external 
library that is made for quite more (pretty much change everything on the 
admin page) seems like a bad idea. 
*Would it be worth it to have these two features implemented into django?*

There are also other projects just to add the autocomplete feature which I 
haven't used nor tested ( 
https://django-autocomplete-light.readthedocs.org/en/master/ and 
https://github.com/crucialfelix/django-ajax-selects ) so the feature looks 
required.






-- 
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/3cd2f357-d298-45ac-a8da-363798f0814f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remove null assingment check for non-nullable fields?

[Dheerendra Rathor]

With respect to rationale 2:
It makes sense to remove this check as database handle these checks very
well. And just like uniqueness checks, it is nice to let database do its
work.

With respect to rationale 1:
Since this behaviour will ask developers to change exception catching from
ValueError to IntegrityError, I guess this will be a huge pain for
developers to migrate considering how lazy we developers are.

In my opinion it is good to remove this check in future version (probably
Django 2.0) and for now a RemovedInDjango1xxWarning can be showed with
ValueError check.

On Tue, 2 Feb 2016 at 23:26 Tim Graham  wrote:

> There's a proposal to remove this behavior:
>
>
> >>> obj.fk = None
> ValueError('Cannot assign None: "Obj.fk" does not allow null values.)
>
>
> (i.e. no more exception if you assign None to a non-nullable foreign key)
>
>
> Rationale presented on the ticket [1]:
>
>- Conceptually it is a programmer's responsibility to validate the
>data assigned to foreign key in a right moment - not necessarily during
>assignment to the model field.
>- This behavior is not symmetrical to other database-related
>constraints as for example unique=True which is deferred to save()
>method (raising IntegrityError
>) or full_clean()
>method (raising ValidationError).
>- In #13776  the decision
>was made that a None value for foreign key field with null=False and
>corresponding form field with required=False should be valid. It means
>that after model instantiation by such a form, the value of a given field
>is empty or just unset (not defined). Whatever the state is, it doesn't
>matter. It shows only that currently discussed check does *not*
>prevent in 100% against having foreign key field with null=False set
>to None. It undermines the legitimacy of presence for the discussed
>check.
>
> Any concerns with this?
>
>
> Its removal helps fix an edge case that regressed in Django 1.8 where if
> you have a model field with blank=False but required=False on the form
> field, an empty form value will be silently ignored and won't overwrite a
> model instance's value. I think it's a sufficient edge case, however, that
> it's not worth backporting this change (if accepted).
>
>
> [1] https://code.djangoproject.com/ticket/25349
>
> --
> 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/a79c63a4-abdf-4cbd-bf96-a4bc2d5b537b%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/CAByqUgiMZgB2LxDyQLW%2B5tLezu8omJihBZExScuSaVPFG4OMYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Remove null assingment check for non-nullable fields?

[Tim Graham]

There's a proposal to remove this behavior:


>>> obj.fk = None
ValueError('Cannot assign None: "Obj.fk" does not allow null values.)


(i.e. no more exception if you assign None to a non-nullable foreign key)


Rationale presented on the ticket [1]:

   - Conceptually it is a programmer's responsibility to validate the data 
   assigned to foreign key in a right moment - not necessarily during 
   assignment to the model field. 
   - This behavior is not symmetrical to other database-related constraints 
   as for example unique=True which is deferred to save() method (raising 
   IntegrityError ) or 
   full_clean() method (raising ValidationError). 
   - In #13776  the decision 
   was made that a None value for foreign key field with null=False and 
   corresponding form field with required=False should be valid. It means 
   that after model instantiation by such a form, the value of a given field 
   is empty or just unset (not defined). Whatever the state is, it doesn't 
   matter. It shows only that currently discussed check does *not* prevent 
   in 100% against having foreign key field with null=False set to None. It 
   undermines the legitimacy of presence for the discussed check.

Any concerns with this?


Its removal helps fix an edge case that regressed in Django 1.8 where if 
you have a model field with blank=False but required=False on the form 
field, an empty form value will be silently ignored and won't overwrite a 
model instance's value. I think it's a sufficient edge case, however, that 
it's not worth backporting this change (if accepted).


[1] https://code.djangoproject.com/ticket/25349

-- 
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/a79c63a4-abdf-4cbd-bf96-a4bc2d5b537b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26165 new Cleanup/optimization wanted to start with a documentation ticket

[Tim Graham]

The FAQ is at: https://github.com/django/django/tree/master/docs/faq
Depending on how much content there is, it might make more sense to add the 
questions on the CSRF reference page instead: 
https://github.com/django/django/blob/master/docs/ref/csrf.txt
Please read the contributing documentation about claiming tickets: 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#claiming-tickets

p.s. I think it's better to use the django-core-mentorship mailing list to 
get help about the basics of contributing. Thanks!

On Tuesday, February 2, 2016 at 4:14:08 PM UTC-5, Vivek unni wrote:
>
> I wanted to start with a documentation ticket while I get myself 
> acquainted with the code base. I have seen the thread referenced and I can 
> make relevant questions and answers from it . These questions and answers 
> will go to the FAQ page regarding why Django's CSRF protection isn't 
> vulernable. Where do I start writing the documentation and how can I claim 
> the ticket ? Some examples will help.
> Thanks in advance.
>

-- 
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/fa19bbdf-47b8-4fdd-904e-917b2ac465ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#26165 new Cleanup/optimization Wanted to start with a documentation ticket

[Vivek unni]

Hi,
I wanted to start with a documentation ticket.
 https://code.djangoproject.com/ticket/26165 
 I have read through the 
thread and have made some questions and answers. How should I proceed? 
Should I claim the ticket ? Where can I start writing?

Thanks in advance
Vivek

-- 
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/713d8815-1dee-45cf-abe8-0a2a168540ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#26165 new Cleanup/optimization wanted to start with a documentation ticket

[Vivek unni]

I wanted to start with a documentation ticket while I get myself acquainted 
with the code base. I have seen the thread referenced and I can make 
relevant questions and answers from it . These questions and answers will 
go to the FAQ page regarding why Django's CSRF protection isn't vulernable. 
Where do I start writing the documentation and how can I claim the ticket ? 
Some examples will help.
Thanks in advance.

-- 
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/2f38936b-7c96-4d30-ae18-6fc064677d24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #10686 - inheritance of extra permissions from base class to child class

[Shai Berger]

Hi Sergei,

Two notes:

1) For Abstract base classes, Meta is inherited by default[1] which would make 
the permissions inherited by default. For multi-table inheritance, this is not 
the case[2].

2) The second option as you presented it, where AssignedTask.Meta's 
permissions are added to its parent's permissions, rather than replacing them, 
appears unpythonic to me. Python, consistently, requires such accumulation in 
inheritence to be explicit.

So, I think I would go with Tim's first suggestion. It means that, if BaseTask 
is concrete, then, indeed, its subclasses might need some boilerplate. Note 
that such boilerplate may be reduced  by other means -- e.g. defining a base-
class for all the Meta's as an independent, non-nested class. At least in 
principle, you could even give this base-Meta a metaclass that will implement 
the unpythonic accumulating-instead-of-overriding inheritence; but I don't 
think Django should do something like that.

HTH,
Shai.

[1] https://docs.djangoproject.com/en/1.9/topics/db/models/#meta-inheritance
[2] https://docs.djangoproject.com/en/1.9/topics/db/models/#meta-and-multi-
table-inheritance

On Tuesday 02 February 2016 15:52:19 Sergei Maertens wrote:
> Hi all,
> 
> I was browsing tickets and stumbled
> upon https://code.djangoproject.com/ticket/10686, which was accepted except
> for lack of documentation. The patch in the mentioned ticket makes it so
> that a Model class that's used as base class with extra permissions:
> 
> class BaseTask(models.Model):
> ...
> class Meta:
>permissions = (
>('view_%(class)s', 'Can view %(class)s'),
>)
> 
> will make those permissions specific for any child classes:
> 
> class TodoTask(BaseTask):
> pass
> 
> 
> class AssignedTask(BaseTask):
> assignee = models.ForeignKey(settings.AUTH_USER_MODEL)
> 
> class Meta:
> permissions = (
> ('reassign_assignedtask', 'Can reassign assigned task')
> )
> 
> 
> 
> 
> With the current patch, TodoTask would have one extra permission:
> view_todotask, and AssignedTask would have two: view_assignedtask and
> reassign_assignedtask.
> 
> Now there were some concerns on the pull request, and input is needed:
> 
> 
>- in its current state, Django will not inherit the base class
>permissions, so AssignedTask would end up only with the
>reassign_assignedtask permission (so missing view_assignedtask). The
> patch ensures that inheritance is applied, and adds an extra Meta option:
> inherit_permissions. Setting that to False yields the current behaviour -
> no base class permissions are inherited. Disadvantages of this approach: -
> yet another Meta attribute
>   - more tight coupling between Meta and django.contrib.permissions
>   (pointed out by Tim Graham)
>   - 'hidden' second feature within the initial enhancee
> 
> Two alternatives to avoid having to add inherit_permisisons have been
> proposed by Tim:
> 
> class AssignedTask(BaseTask):
> assignee = models.ForeignKey(settings.AUTH_USER_MODEL)
> 
> class Meta:
> permissions = BaseTask.Meta.permissions + (
> ('reassign_assignedtask', 'Can reassign assigned task')
> )
> 
> It looks like the inheritance of permissions would not be a default then,
> which would require the other model to be changed to:
> 
> class TodoTask(BaseTask):
> class Meta:
> permissions = BaseTask.Meta.permissions
> 
> 
> In my opinition this introduces boilerplate which you get for free if the
> permissions are inherited by default. On the upside, it is more explicit.
> 
> Another suggestion was to use good old fashioned Python inheritance:
> 
> class TodoTask(BaseTask):
> class Meta(BaseTask.Meta):
>pass
> 
> 
> class AssignedTask(BaseTask):
> assignee = models.ForeignKey(settings.AUTH_USER_MODEL)
> 
> class Meta(BaseTask.Meta):
> permissions = (
> ('reassign_assignedtask', 'Can reassign assigned task')
> )
> 
> 
> The latter two suggestions would ofcourse require fixing the patch, but
> that's an implementation detail.
> 
> Input would be greatly valued.

Re: remove support for unsalted password hashers?

[charettes]

> For testing, Django provides force_login(). This method skips password 
hashing
> and logs a user in for a test. For tests that want a logged in user and 
do not
> care about how the password was verified, this seems like a good choice.
> Assuming this was used throughout, would this be sufficient for handling 
this
> performance concern? 

I didn't know about that force_login() method. I see that a lot of admin 
tests
have been converted to use it so far which is great but there's still a 
couple
of occurence of login() that looks like they could be converted.

> Tests that verify the password hasher will need to run the hash algorithm
> regardless.

I'm aware of that but this only represents a small fraction of the tests.

Le mardi 2 février 2016 13:49:31 UTC-5, Jon Dufresne a écrit :
>
> On Tue, Feb 2, 2016 at 10:35 AM, charettes  > wrote: 
> >> That hasher, being the fastest non-plaintext hasher around, is quite 
> >> useful 
> >> when running tests: it allows login checks to be performed much faster. 
> > 
> > This argument came up a couple of time in the past and from what I 
> remember 
> > the Django test suite itself spends a significant amount of time hashing 
> > passwords. 
> > 
> > I understand that we want to avoid shipping a plaintext password hasher 
> in 
> > `django.contrib.auth.hashers` for the sake of not exposing a footgun-API 
> but 
> > what if we shipped one in the `django.contrib.auth.test` package 
> instead? 
> > 
> > We could document its use for testing purposes only and would make the 
> > complete deprecation of unsafe hashers easier. 
>
> For testing, Django provides force_login(). This method skips password 
> hashing and logs a user in for a test. For tests that want a logged in 
> user and do not care about how the password was verified, this seems 
> like a good choice. Assuming this was used throughout, would this be 
> sufficient for handling this performance concern? 
>
> Tests that verify the password hasher will need to run the hash 
> algorithm regardless. 
>
>
> https://docs.djangoproject.com/en/1.9/topics/testing/tools/#django.test.Client.force_login
>  
>

-- 
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/57f549d2-7eb3-4300-9e7e-c0aad97b0bf8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[charettes]

> For testing, Django provides force_login(). This method skips password 
hashing
> and logs a user in for a test. For tests that want a logged in user and 
do not
> care about how the password was verified, this seems like a good choice.
> Assuming this was used throughout, would this be sufficient for handling 
this
> performance concern? 

I didn't know about that force_login() method. I see that a lot of admin 
tests
have been converted to use it so far which is great but there's still a 
couple
of occurence of login() that looks like they could be converted.

> Tests that verify the password hasher will need to run the hash algorithm
> regardless.

I'm aware of that but this only represents a small fraction of the tests.

Le mardi 2 février 2016 13:49:31 UTC-5, Jon Dufresne a écrit :
>
> On Tue, Feb 2, 2016 at 10:35 AM, charettes  > wrote: 
> >> That hasher, being the fastest non-plaintext hasher around, is quite 
> >> useful 
> >> when running tests: it allows login checks to be performed much faster. 
> > 
> > This argument came up a couple of time in the past and from what I 
> remember 
> > the Django test suite itself spends a significant amount of time hashing 
> > passwords. 
> > 
> > I understand that we want to avoid shipping a plaintext password hasher 
> in 
> > `django.contrib.auth.hashers` for the sake of not exposing a footgun-API 
> but 
> > what if we shipped one in the `django.contrib.auth.test` package 
> instead? 
> > 
> > We could document its use for testing purposes only and would make the 
> > complete deprecation of unsafe hashers easier. 
>
> For testing, Django provides force_login(). This method skips password 
> hashing and logs a user in for a test. For tests that want a logged in 
> user and do not care about how the password was verified, this seems 
> like a good choice. Assuming this was used throughout, would this be 
> sufficient for handling this performance concern? 
>
> Tests that verify the password hasher will need to run the hash 
> algorithm regardless. 
>
>
> https://docs.djangoproject.com/en/1.9/topics/testing/tools/#django.test.Client.force_login
>  
>

-- 
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/38defa26-4380-4890-ba48-bbc822856a72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Donald Stufft]

> On Feb 2, 2016, at 1:52 PM, Tim Graham  wrote:
> 
> Just to be clear, my proposal here is only about removing 
> UnsaltedSHA1PasswordHasher and UnsaltedMD5PasswordHasher. The salted versions 
> of these hashers remain.



It seems silly to remove the unsalted options and leave the salted options, 
they are basically equally [1] as secure since computational power is such that 
it is, that it’s not really worth it to use rainbow tables anymore anyways.

[1] Ok, Ok, technically salted are a wee bit more secure, but given that you 
can compute the MD5 of every single possible lower case alpha numeric of 6 
characters or less in under a minute on a single regular desktop/server.. I 
don’t believe the distinction is useful.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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/123D52C5-FE34-4B70-9D1D-8B5B702A405A%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: remove support for unsalted password hashers?

[Tim Graham]

Just to be clear, my proposal here is only about removing 
UnsaltedSHA1PasswordHasher and UnsaltedMD5PasswordHasher. The salted 
versions of these hashers remain. I don't think the unsalted versions have 
any speed advantages as far as testing goes compared to the salted 
versions? Django's test settings use MD5PasswordHasher, not the unsalted 
version.

On Tuesday, February 2, 2016 at 12:23:50 PM UTC-5, Raphaël Barrois wrote:
>
> Hi Tim, 
>
> I would suggest removing those hashers from the default list, but keeping 
> at least the 
> django.contrib.auth.hashers.UnsaltedMD5PasswordHasher around. 
>
> That hasher, being the fastest non-plaintext hasher around, is quite 
> useful when running tests: it allows login checks 
> to be performed much faster. 
>
> Beyond this, the idea seems great — it's still pretty easy for a site to 
> keep them around if it needs them. 
>
>
> -- 
> Raphaël 
>
> On Tue, 2 Feb 2016 08:10:50 -0800 (PST) 
> Tim Graham  wrote: 
>
> > Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support 
> for 
> > salted SHA1 with automatic upgrade of passwords [0]. 
> > 
> > In Django 1.4, the new password hashing machinery was added and some 
> users 
> > complained that they couldn't upgrade because the password format from 
> > Django 0.90 was no longer accepted (passwords encodings starting with 
> > "md5$$" or "sha1$$", though the ticket suggests Django never used the 
> > latter prefix) [1]. 
> > 
> > I wonder if it's about time to remove these hashers [2]? I think it'd be 
> > okay for users who haven't logged in since Django 0.90 to reset their 
> > password (assuming the site provides that mechanism). I would consider 
> > recommending that site administrators mark any unsalted passwords 
> > "unusable" to mitigate the possibility of leaking unsalted passwords in 
> the 
> > event the database is compromised. 
> > 
> > I think this is as simple as: 
> > 
> > users = User.objects.filter(password__startswith='md5$$') 
> > for user in users: 
> >  user.set_unusable_password() 
> >  user.save(update_fields=['password'] 
> > 
> > [0] https://code.djangoproject.com/ticket/18144#comment:18 
> > [1] https://code.djangoproject.com/ticket/18144 
> > [2] 
> > 
> https://github.com/django/django/compare/master...timgraham:remove-unsalted-hashers
>  
> > 
>
>

-- 
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/ff38c257-7218-446b-9de8-0d14d5f108f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Jon Dufresne]

On Tue, Feb 2, 2016 at 10:35 AM, charettes  wrote:
>> That hasher, being the fastest non-plaintext hasher around, is quite
>> useful
>> when running tests: it allows login checks to be performed much faster.
>
> This argument came up a couple of time in the past and from what I remember
> the Django test suite itself spends a significant amount of time hashing
> passwords.
>
> I understand that we want to avoid shipping a plaintext password hasher in
> `django.contrib.auth.hashers` for the sake of not exposing a footgun-API but
> what if we shipped one in the `django.contrib.auth.test` package instead?
>
> We could document its use for testing purposes only and would make the
> complete deprecation of unsafe hashers easier.

For testing, Django provides force_login(). This method skips password
hashing and logs a user in for a test. For tests that want a logged in
user and do not care about how the password was verified, this seems
like a good choice. Assuming this was used throughout, would this be
sufficient for handling this performance concern?

Tests that verify the password hasher will need to run the hash
algorithm regardless.

https://docs.djangoproject.com/en/1.9/topics/testing/tools/#django.test.Client.force_login

-- 
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/CADhq2b5%3DnqrD2GOTTg4hjT4KxRUFGGT0tZZHCYypdggH-0ePqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[charettes]

> That hasher, being the fastest non-plaintext hasher around, is quite 
useful
> when running tests: it allows login checks to be performed much faster. 

This argument came up a couple of time in the past and from what I remember
the Django test suite itself spends a significant amount of time hashing
passwords.

I understand that we want to avoid shipping a plaintext password hasher in
`django.contrib.auth.hashers` for the sake of not exposing a footgun-API but
what if we shipped one in the `django.contrib.auth.test` package instead?

We could document its use for testing purposes only and would make the
complete deprecation of unsafe hashers easier.

Simon

Le mardi 2 février 2016 12:23:50 UTC-5, Raphaël Barrois a écrit :
>
> Hi Tim, 
>
> I would suggest removing those hashers from the default list, but keeping 
> at least the 
> django.contrib.auth.hashers.UnsaltedMD5PasswordHasher around. 
>
> That hasher, being the fastest non-plaintext hasher around, is quite 
> useful when running tests: it allows login checks 
> to be performed much faster. 
>
> Beyond this, the idea seems great — it's still pretty easy for a site to 
> keep them around if it needs them. 
>
>
> -- 
> Raphaël 
>
> On Tue, 2 Feb 2016 08:10:50 -0800 (PST) 
> Tim Graham  wrote: 
>
> > Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support 
> for 
> > salted SHA1 with automatic upgrade of passwords [0]. 
> > 
> > In Django 1.4, the new password hashing machinery was added and some 
> users 
> > complained that they couldn't upgrade because the password format from 
> > Django 0.90 was no longer accepted (passwords encodings starting with 
> > "md5$$" or "sha1$$", though the ticket suggests Django never used the 
> > latter prefix) [1]. 
> > 
> > I wonder if it's about time to remove these hashers [2]? I think it'd be 
> > okay for users who haven't logged in since Django 0.90 to reset their 
> > password (assuming the site provides that mechanism). I would consider 
> > recommending that site administrators mark any unsalted passwords 
> > "unusable" to mitigate the possibility of leaking unsalted passwords in 
> the 
> > event the database is compromised. 
> > 
> > I think this is as simple as: 
> > 
> > users = User.objects.filter(password__startswith='md5$$') 
> > for user in users: 
> >  user.set_unusable_password() 
> >  user.save(update_fields=['password'] 
> > 
> > [0] https://code.djangoproject.com/ticket/18144#comment:18 
> > [1] https://code.djangoproject.com/ticket/18144 
> > [2] 
> > 
> https://github.com/django/django/compare/master...timgraham:remove-unsalted-hashers
>  
> > 
>
>

-- 
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/b24d4e9e-97d5-4d80-9afc-00b561c1b8bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Raphaël Barrois]

Hi Tim,

I would suggest removing those hashers from the default list, but keeping at 
least the
django.contrib.auth.hashers.UnsaltedMD5PasswordHasher around.

That hasher, being the fastest non-plaintext hasher around, is quite useful 
when running tests: it allows login checks
to be performed much faster.

Beyond this, the idea seems great — it's still pretty easy for a site to keep 
them around if it needs them.


-- 
Raphaël

On Tue, 2 Feb 2016 08:10:50 -0800 (PST)
Tim Graham  wrote:

> Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support for 
> salted SHA1 with automatic upgrade of passwords [0].
> 
> In Django 1.4, the new password hashing machinery was added and some users 
> complained that they couldn't upgrade because the password format from 
> Django 0.90 was no longer accepted (passwords encodings starting with 
> "md5$$" or "sha1$$", though the ticket suggests Django never used the 
> latter prefix) [1].
> 
> I wonder if it's about time to remove these hashers [2]? I think it'd be 
> okay for users who haven't logged in since Django 0.90 to reset their 
> password (assuming the site provides that mechanism). I would consider 
> recommending that site administrators mark any unsalted passwords 
> "unusable" to mitigate the possibility of leaking unsalted passwords in the 
> event the database is compromised.
> 
> I think this is as simple as:
> 
> users = User.objects.filter(password__startswith='md5$$')
> for user in users:
>  user.set_unusable_password()
>  user.save(update_fields=['password']
> 
> [0] https://code.djangoproject.com/ticket/18144#comment:18
> [1] https://code.djangoproject.com/ticket/18144
> [2] 
> https://github.com/django/django/compare/master...timgraham:remove-unsalted-hashers
> 

-- 
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/20160202182336.719be5ca%40ithor.polyconseil.fr.
For more options, visit https://groups.google.com/d/optout.

Re: [admin] submit_row template tag reusability issue

[Tim Graham]

The patch is 5 years old and doesn't apply cleanly, so it needs improvement 
in that sense but that shouldn't be difficult. The main blocker to getting 
it merged looks like "Needs tests."

On Tuesday, February 2, 2016 at 10:58:40 AM UTC-5, Federico Capoano wrote:
>
> Hi Tim,
>
> thank you for letting me know of the open ticket.
> The "patch needs improvement" flag is set to "no". Is that correct or not?
>
> Federico
>
> On Mon, Feb 1, 2016 at 1:18 PM Tim Graham  > wrote:
>
>> Here is an accepted ticket: https://code.djangoproject.com/ticket/13875
>>
>> Feel free to update and/or improve the patch, add tests, and send a pull 
>> request. Thanks!
>>
>>
>> On Monday, February 1, 2016 at 6:18:35 AM UTC-5, Federico Capoano wrote:
>>>
>>> Hi all,
>>>
>>> I came across the need of modifying the submit row functionality in the 
>>> django admin and I found out a small issue which prevents me from modifying 
>>> the template without rewriting (duplicating) also the templatetag entirely.
>>>
>>> If you take a look at the code of submit_row templatetag 
>>> ,
>>>  
>>> you will notice the original view context is not passed entirely to the 
>>> return statement. A new ctx dictionary is created and filled only with a 
>>> smaller subset of key/value pairs.
>>>
>>> I took a quick look at other template tags and I noticed they return the 
>>> entire context and not a stripped version of it.
>>>
>>> I would prefer submit_row to behave in the same way as the other 
>>> templatetags so I wouldn't have to duplicate its code to add new context 
>>> values to it.
>>> If there's consensus on this issue I can create a ticket and send a pull 
>>> request, let me know.
>>>
>>> Federico
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/yrngp53RvxY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/bbb82460-8a55-47ff-8e7f-acfc063f6cf0%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/0dfaacf4-49d4-4201-8ee8-080925c33545%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

remove support for unsalted password hashers?

[Tim Graham]

Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support for 
salted SHA1 with automatic upgrade of passwords [0].

In Django 1.4, the new password hashing machinery was added and some users 
complained that they couldn't upgrade because the password format from 
Django 0.90 was no longer accepted (passwords encodings starting with 
"md5$$" or "sha1$$", though the ticket suggests Django never used the 
latter prefix) [1].

I wonder if it's about time to remove these hashers [2]? I think it'd be 
okay for users who haven't logged in since Django 0.90 to reset their 
password (assuming the site provides that mechanism). I would consider 
recommending that site administrators mark any unsalted passwords 
"unusable" to mitigate the possibility of leaking unsalted passwords in the 
event the database is compromised.

I think this is as simple as:

users = User.objects.filter(password__startswith='md5$$')
for user in users:
 user.set_unusable_password()
 user.save(update_fields=['password']

[0] https://code.djangoproject.com/ticket/18144#comment:18
[1] https://code.djangoproject.com/ticket/18144
[2] 
https://github.com/django/django/compare/master...timgraham:remove-unsalted-hashers

-- 
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/57cc065d-8349-4c0a-a731-4091206f194b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [admin] submit_row template tag reusability issue

[Federico Capoano]

Hi Tim,

thank you for letting me know of the open ticket.
The "patch needs improvement" flag is set to "no". Is that correct or not?

Federico

On Mon, Feb 1, 2016 at 1:18 PM Tim Graham  wrote:

> Here is an accepted ticket: https://code.djangoproject.com/ticket/13875
>
> Feel free to update and/or improve the patch, add tests, and send a pull
> request. Thanks!
>
>
> On Monday, February 1, 2016 at 6:18:35 AM UTC-5, Federico Capoano wrote:
>>
>> Hi all,
>>
>> I came across the need of modifying the submit row functionality in the
>> django admin and I found out a small issue which prevents me from modifying
>> the template without rewriting (duplicating) also the templatetag entirely.
>>
>> If you take a look at the code of submit_row templatetag
>> ,
>> you will notice the original view context is not passed entirely to the
>> return statement. A new ctx dictionary is created and filled only with a
>> smaller subset of key/value pairs.
>>
>> I took a quick look at other template tags and I noticed they return the
>> entire context and not a stripped version of it.
>>
>> I would prefer submit_row to behave in the same way as the other
>> templatetags so I wouldn't have to duplicate its code to add new context
>> values to it.
>> If there's consensus on this issue I can create a ticket and send a pull
>> request, let me know.
>>
>> Federico
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/yrngp53RvxY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/bbb82460-8a55-47ff-8e7f-acfc063f6cf0%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/CAERYH6Vfrb%2B4YD%2B-9bsCWdGPDR8QzxGYJrC9e7PH9uWQJ%3D7asg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

[guettli]

thank you all for your feedback.

I think it would be good to reference from the individual page to the 
matching comparison grid (if one exists). It tells
newcomers: Professionals do re-use, they don't re-invent.

For example the python docs sometimes have a box called "See also" which 
contains links to related pages.

I found such a box at the bottom of "hashlib": 
https://docs.python.org/2/library/hashlib.html#key-derivation

Regards,
  Thomas Güttler

Am Dienstag, 2. Februar 2016 15:45:23 UTC+1 schrieb Sergei Maertens:
>
> My main concern is that it might appear that Django officially endorses 
> the website, and that it might not be clear to developers that Django isn't 
> directly involved with all those third party packages - which could be 
> potentially harmful.
>
> I'm also think that if you start linking to a grid for pagination, that 
> you should do so for alternative form libraries, template engines, maybe 
> even ORM-stuff if that exists. Basically for every (small or big) component 
> that Django offers. Markus explained it better by using the term 'scattered 
> all over the documentation'.
>
> I would have no problems with a page/section in the docs where libraries 
> or resources like djangopackages.com are linked, centralized in a single 
> place. You lose the relevance on the subject at hand though.
>
> DRF links to extensions, where I assume that Tom has checked all of them 
> and deemed them worthy. It links to a known set of packages, and to me it 
> seems that Tom officially endorses them and finds the quality sufficicient. 
> That's something you don't get with a link to a grid comparison where the 
> content can change multiple time per day.
>
> On Monday, February 1, 2016 at 12:06:23 PM UTC+1, Federico Capoano wrote:
>>
>> It seems like a good proposal, It would be good to know why Sergei 
>> doesn't think it is appropiate for Django to add links to third party 
>> package comparison grids.
>>
>> django-rest-framework links to third party extensions in its 
>> documentation and this had a positive effect on the whole DRF ecosystem.
>>
>> Federico
>>
>>
>> On Monday, February 1, 2016 at 10:39:44 AM UTC+1, guettli wrote:
>>>
>>> This ticket was closed as invalid: 
>>> https://code.djangoproject.com/ticket/26159
>>>
>>> {{{
>>>
>>> Here comes a pull request to add a link to the djangopackages comparison 
>>> grid "Pagination".
>>> Background: The pagination in django core is only very basic. Most 
>>> people want more. I think re-use helps more then re-inventing :-)
>>> }}}
>>>
>>>
>>> {{{
>>> sergei-maertens
>>>
>>> Resolution set to invalid
>>> Status changed from new to closed
>>>
>>> I don't think the docs are the appropriate place to point out 
>>> alternatives. I feel if Django starts going down that road, then you should 
>>> do the same not only for pagination, but for forms, views, other db 
>>> adapters, other template engines... I think it's a slippery slope.
>>>
>>> While I think that djangopackages.com is a great resource, I'm not sure 
>>> if it (and no other resources) should be 'officially endorsed' by Django in 
>>> the docs.
>>> }}}
>>>
>>> I think a lot of time gets wasted by re-inventing stuff. Yes, 
>>> programmers love to program. But time have
>>> changed. There are a lot of great re-usable apps and libraries and 
>>> programmers who wants to
>>> get things done use them.
>>>
>>> What do you think for *this* issue: the docs for pagination should point 
>>> to the comparison grid or not?
>>>
>>> Regards,
>>>   Thomas Güttler
>>>
>>>

-- 
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/6eb3d40e-8b6c-4b70-b3c5-8dc679520532%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

[Sergei Maertens]

My main concern is that it might appear that Django officially endorses the 
website, and that it might not be clear to developers that Django isn't 
directly involved with all those third party packages - which could be 
potentially harmful.

I'm also think that if you start linking to a grid for pagination, that you 
should do so for alternative form libraries, template engines, maybe even 
ORM-stuff if that exists. Basically for every (small or big) component that 
Django offers. Markus explained it better by using the term 'scattered all 
over the documentation'.

I would have no problems with a page/section in the docs where libraries or 
resources like djangopackages.com are linked, centralized in a single 
place. You lose the relevance on the subject at hand though.

DRF links to extensions, where I assume that Tom has checked all of them 
and deemed them worthy. It links to a known set of packages, and to me it 
seems that Tom officially endorses them and finds the quality sufficicient. 
That's something you don't get with a link to a grid comparison where the 
content can change multiple time per day.

On Monday, February 1, 2016 at 12:06:23 PM UTC+1, Federico Capoano wrote:
>
> It seems like a good proposal, It would be good to know why Sergei doesn't 
> think it is appropiate for Django to add links to third party package 
> comparison grids.
>
> django-rest-framework links to third party extensions in its documentation 
> and this had a positive effect on the whole DRF ecosystem.
>
> Federico
>
>
> On Monday, February 1, 2016 at 10:39:44 AM UTC+1, guettli wrote:
>>
>> This ticket was closed as invalid: 
>> https://code.djangoproject.com/ticket/26159
>>
>> {{{
>>
>> Here comes a pull request to add a link to the djangopackages comparison 
>> grid "Pagination".
>> Background: The pagination in django core is only very basic. Most people 
>> want more. I think re-use helps more then re-inventing :-)
>> }}}
>>
>>
>> {{{
>> sergei-maertens
>>
>> Resolution set to invalid
>> Status changed from new to closed
>>
>> I don't think the docs are the appropriate place to point out 
>> alternatives. I feel if Django starts going down that road, then you should 
>> do the same not only for pagination, but for forms, views, other db 
>> adapters, other template engines... I think it's a slippery slope.
>>
>> While I think that djangopackages.com is a great resource, I'm not sure 
>> if it (and no other resources) should be 'officially endorsed' by Django in 
>> the docs.
>> }}}
>>
>> I think a lot of time gets wasted by re-inventing stuff. Yes, programmers 
>> love to program. But time have
>> changed. There are a lot of great re-usable apps and libraries and 
>> programmers who wants to
>> get things done use them.
>>
>> What do you think for *this* issue: the docs for pagination should point 
>> to the comparison grid or not?
>>
>> Regards,
>>   Thomas Güttler
>>
>>

-- 
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/c00ea768-7559-4145-9ec5-a49c1bec6f39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#10686 - inheritance of extra permissions from base class to child class

[Sergei Maertens]

Hi all,

I was browsing tickets and stumbled 
upon https://code.djangoproject.com/ticket/10686, which was accepted except 
for lack of documentation. The patch in the mentioned ticket makes it so 
that a Model class that's used as base class with extra permissions:

class BaseTask(models.Model):
...
class Meta:
   permissions = (
   ('view_%(class)s', 'Can view %(class)s'),
   )

will make those permissions specific for any child classes:

class TodoTask(BaseTask):
pass


class AssignedTask(BaseTask):
assignee = models.ForeignKey(settings.AUTH_USER_MODEL)

class Meta:
permissions = (
('reassign_assignedtask', 'Can reassign assigned task')
)

 


With the current patch, TodoTask would have one extra permission: 
view_todotask, and AssignedTask would have two: view_assignedtask and 
reassign_assignedtask.

Now there were some concerns on the pull request, and input is needed:


   - in its current state, Django will not inherit the base class 
   permissions, so AssignedTask would end up only with the 
   reassign_assignedtask permission (so missing view_assignedtask). The patch 
   ensures that inheritance is applied, and adds an extra Meta option: 
   inherit_permissions. Setting that to False yields the current behaviour - 
   no base class permissions are inherited. Disadvantages of this approach:
  - yet another Meta attribute
  - more tight coupling between Meta and django.contrib.permissions 
  (pointed out by Tim Graham)
  - 'hidden' second feature within the initial enhancee
   
Two alternatives to avoid having to add inherit_permisisons have been 
proposed by Tim:

class AssignedTask(BaseTask):
assignee = models.ForeignKey(settings.AUTH_USER_MODEL)

class Meta:
permissions = BaseTask.Meta.permissions + (
('reassign_assignedtask', 'Can reassign assigned task')
)

It looks like the inheritance of permissions would not be a default then, 
which would require the other model to be changed to:

class TodoTask(BaseTask):
class Meta:
permissions = BaseTask.Meta.permissions


In my opinition this introduces boilerplate which you get for free if the 
permissions are inherited by default. On the upside, it is more explicit.

Another suggestion was to use good old fashioned Python inheritance:

class TodoTask(BaseTask):
class Meta(BaseTask.Meta):
   pass


class AssignedTask(BaseTask):
assignee = models.ForeignKey(settings.AUTH_USER_MODEL)

class Meta(BaseTask.Meta):
permissions = ( 
('reassign_assignedtask', 'Can reassign assigned task')
)


The latter two suggestions would ofcourse require fixing the patch, but 
that's an implementation detail.

Input would be greatly valued.

-- 
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/646d7295-5183-42b1-be32-30967794b051%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

[Tore Lundqvist]

Ok, got that sorted now. How about the fix, is it reasonable?


Den tisdag 2 februari 2016 kl. 11:51:19 UTC+1 skrev is_null:
>
> Just click "Details" and then "Console output". You'll find this: 
>
> + flake8 
> ./django/contrib/sessions/backends/db.py:91:30: E901 SyntaxError: invalid 
> syntax 
>
> ERROR: 
> /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py 
> Imports are incorrectly sorted. 
> --- 
> /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py:before 
> 2016-02-01 16:04:24.701654 
> +++ 
> /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py:after 
> 2016-02-01 16:04:30.952126 
> @@ -1,8 +1,10 @@ 
>  import logging 
>
> -from django.contrib.sessions.backends.base import CreateError, 
> SessionBase, UpdateError 
> +from django.contrib.sessions.backends.base import ( 
> +CreateError, SessionBase, UpdateError, 
> +) 
>  from django.core.exceptions import SuspiciousOperation 
> -from django.db import IntegrityError, router, transaction, DatabaseError 
> +from django.db import DatabaseError, IntegrityError, router, transaction 
>  from django.utils import timezone 
>  from django.utils.encoding import force_text 
>  from django.utils.functional import cached_property 
>

-- 
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/5a408dcd-bc9b-47bf-913c-18b0fb528d24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

[James Pic]

Just click "Details" and then "Console output". You'll find this:

+ flake8
./django/contrib/sessions/backends/db.py:91:30: E901 SyntaxError: invalid syntax

ERROR: /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py
Imports are incorrectly sorted.
--- /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py:before
2016-02-01 16:04:24.701654
+++ /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py:after
2016-02-01 16:04:30.952126
@@ -1,8 +1,10 @@
 import logging

-from django.contrib.sessions.backends.base import CreateError,
SessionBase, UpdateError
+from django.contrib.sessions.backends.base import (
+CreateError, SessionBase, UpdateError,
+)
 from django.core.exceptions import SuspiciousOperation
-from django.db import IntegrityError, router, transaction, DatabaseError
+from django.db import DatabaseError, IntegrityError, router, transaction
 from django.utils import timezone
 from django.utils.encoding import force_text
 from django.utils.functional import cached_property

-- 
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/CALC3Kadknk4-8N4CPPNC3_40rwQrSBrevqkKr9LE%2BswLMKG-3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

[Tore Lundqvist]

Thanks for the feedback!

I have updated the PR, can someone have a look at it again?

I noticed that there where failing checks (flake8, isort) but it does not 
say why that it, do I need to fix something?

Cheers 
Tore Lundqvist

Den fredag 29 januari 2016 kl. 15:20:11 UTC+1 skrev Tore Lundqvist:
>
> Hi, everyone!
>
> I confirmed this (21608) non critical security bug a while ago and have 
> sense then made a unit test and a fix for it.
> I have not gotten any feedback on my PR yet, is there something more I 
> need to do to have someone look at this?
>
> Best Regards
> Tore Lundqvist
>

-- 
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/438eb540-cf30-4858-85ed-bf18ec275075%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Query on BooleanField with values other than True and False, bug or intentional?

[Hanne Moa]

I don't think enforcing it would be pythonic.

Once upon a time, Python lacked True and False, all you had were
truthy and falsey and maybe per-project/team constants:

http://python-history.blogspot.no/2013/11/story-of-none-true-false.html

I remember the arguments when bool() was added. Those against were
worried that it would send a signal that would lead to a slippery
slope where truthy and falsey would disappear because people would
insist that "it's pretty sloppy to not enforce an explicit boolean
value and can lead to subtle bugs".

Well..


On 31 January 2016 at 10:34, Adam Johnson  wrote:
> Just to play devil's advocate... you're all worrying about one simple case;
> there are infinite variants of it with subtle bugs, for example imagine the
> same situation but with Value:
>
> Whatever.object.filter(is_active=Value('false'))
>
> The ORM can't predict the type of a Value call - pretty much by definition,
> since it's a raw value passed to the database. So you might be able to fix
> BooleanField for a few cases, but you can't fix them all..
>
>
>
> On Friday, January 29, 2016 at 10:38:52 PM UTC, Chris Foresman wrote:
>>
>> Sorry, sbrandt noted the issue of subtle bugs, not Maxime.
>>
>>
>> On Friday, January 29, 2016 at 4:37:51 PM UTC-6, Chris Foresman wrote:
>>>
>>> I have to agree here; it's pretty sloppy to not enforce an explicit
>>> boolean value and can lead to subtle bugs. In addition to the one mentioned
>>> by Maxime, consider the case of a nullable boolean field:
>>>
>>> >>> bool(None)
>>> False
>>>
>>> Maybe that field has a better converter for possible values and
>>> explicitly allows `None`, but I think it would be fairly trivial to add a
>>> stricter check and pretty easy to fix code that's not backwards compatible
>>> with find/replace.
>>>
>>>
>>> On Friday, January 22, 2016 at 3:18:45 PM UTC-6, Maxime Lorant wrote:

 At least, the behaviour is predictable : it uses `bool(value)`. I
 believe it is not a bug but more a question about the input definition:
 should we allow non boolean value? I don't see any problem here accepting a
 string as a `True` value, it is the job of the user to ensure the value is
 castable to a boolean.

 The same behaviour is found on `IntegerField` for example:
 `Model.objects.filter(pk="foo")` raises `ValueError: invalid literal for
 int() with base 10: 'foo'` which implies the ORM tried to cast 'foo' as an
 integer.

 On Friday, January 22, 2016 at 8:51:41 PM UTC+1, Kaveh wrote:
>
> Today I discovered I can use strings and numbers to query on
> BooleanFields.
>
> Let's say we have the following model:
>
> class Whatever(models.Model):
> name = models.CharField(max_length=200)
> is_active = models.BooleanField()
>
> The following queries return all instances which their `is_active`
> field is True:
>
> Whatever.object.filter(is_active=True)
> Whatever.object.filter(is_active='some_random_text')
> Whatever.object.filter(is_active=777)
>
> and the followings return the ones which are False:
>
> Whatever.object.filter(is_active=False)
> Whatever.object.filter(is_active='')
> Whatever.object.filter(is_active=0)
>
> Is this behaviour intentional or is it a bug? Should queries on
> BooleanFields accept strings and numbers?
>
> --
> 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/ec95ccb7-5ca0-410c-a52b-1ccf75f5d766%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/CACQ%3Drre6rRkdZWT7zjyiwfYvNxK2cXYEwHTvuVzy%3DREubO9g-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.