Re: Composite key development

[Julien Phalip]

Thank you Anssi. It’s very useful to have your perspective as you’ve done a
lot of oversight work on this specific feature before and have lots of
experience working with the ORM internals.

So it seems like the consensus at this point is to use Michal’s original
work as a basis. I like the way you’ve broken down the different steps.
This makes sense and would likely increase chances for eventually reaching
the end goal. Each one of those steps could potentially be fleshed out as
independent DEPs at some point.

Personally I’m also very keen to make this happen so I’m volunteering to
provide oversight and help with documentation, testing and code reviews.

This approach also seems in line with what Asif mentioned earlier about his
own work. Let’s give him a chance to provide some updates on this when he’s
ready, and then we can take it from there.

Thanks all!

Julien

On Mon, Mar 20, 2017 at 1:14 AM, Anssi Kääriäinen 
wrote:

> Just my late 2 cents to this...
>
> First, I wouldn't put too much weight on the DEP proposals. Looking back
> to them now, I don't think they went to the right direction.
>
> For Michal Petrucha's work, it was really close to being merged some years
> ago. The problem was that migrations happened at the same time, and that
> resulted in need of substantial changes to Michal's work, and unfortunately
> this never happened. So, I'd put a lot of weight on this work.
>
> If I'd were to take on this task, I'd try to develop the feature with the
> idea of merging the work in multiple batches. For example this might be a
> possible plan:
>   1. Introduce virtual/composite field, only CREATE TABLE migrations
> support at this point, not documented as public API
>   2. Add support for primary key and unique composite fields, again
> non-public
>   3. Work on foreign keys, again non-public
>   4. Migrations support
>   5. Make the work public API (that is, document the work)
>
> This would give a chance to get the work done in incremental pieces. Doing
> this all in one go is such a large task that there is a big risk of not
> getting this done at all.
>
> Whatever approach you take, I really hope you'll be able to work on this
> and get this long waited feature in to Django.
>
>  - Anssi
>
> On Wednesday, March 1, 2017 at 7:08:35 AM UTC+2, Asif Saifuddin wrote:
>>
>> Hi Julien,
>>
>> I will publish it very soon.
>>
>> Thanks
>>
>> On Wednesday, March 1, 2017 at 5:58:50 AM UTC+6, Julien Phalip wrote:
>>>
>>> Hi Asif,
>>>
>>> That sounds good. On first look I did have some reservations about some
>>> of the design details in the current DEP, especially around the observer
>>> pattern for data binding. But I’m going to have to dig deeper into the
>>> implementation to get a clearer idea.
>>>
>>> It’d be great if you could publish your work-in-progress at some point
>>> so we can discuss the approach in more detail.
>>>
>>> Thanks,
>>>
>>> Julien
>>>
>>> On Mon, Feb 27, 2017 at 9:03 PM, Asif Saifuddin 
>>> wrote:
>>>
 Hi Julian,

 I have been also reviewing and studying the previous works, deps,
 discussions, codes and tickets. I have also been working to prepare a new
 dep based on the previous works.

 Like what Michal said, from my observation, I found the works and
 approaches of Michal is quite better and it's possible to break the work
 down into smaller parts to implement gradually.

 I am not quite sure how much work or which approaches of  Thomas
 Stephenson in 2015 could be mixed or needed with Michal's approach. In my
 humble opinion Michal spent more time in working on this and I also found
 his insights and suggestions on this topic more sensible.

 I would also like to work on this. My Dep is not yet ready for a push.

 You could certainly review and give you input on the Dep. Some core
 members suggested me to finalize a Dep before div into code.

 Let me know what your thoughts.

 Regards,

 Asif

 I have also contact with

 On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens
 wrote:
>
> Hi all,
>
> My company (Citus Data) is interested in sponsoring some Django work.
> In particular work on support for composite primary keys. From what I
> understand this wouldn't be the first time the work has been explored and
> it sounds like it has a number of intricacies to it (
> https://github.com/django/deps/blob/master/draft/0191-compo
> site-fields.rst and https://github.com/django/deps
> /blob/master/draft/0192-standalone-composite-fields.rst). Our hope
> here is that it would be done in line with something that could eventually
> become part of an official Django release vs. a one-off work around.
>
> While we know there's no guarantee of it being accepted, we'd love to
> find someone with some knowledge of all the existing areas that would have
> 

Re: Deprecate is_superuser, is_staff and is_active

[Collin Anderson]

Hi Thomas,

"If the user should have all permissions, then why not give him all these
permissions at database level?" - I have some use cases where there are
only 3-5 people that need to log into the admin. I don't really need to set
different levels of access for different people. I also don't want to have
to go through and add new permissions to every person every time I add a
model. So, I just mark them all as is_superuser and don't use permissions
at all. It keeps things simple.

Something like this might handle your situation:
class MyUser:
# etc
is_superuser = False
is_staff = property(lambda u: u.has_perm('admin'))

Collin

On Fri, Mar 24, 2017 at 8:55 AM, guettli 
wrote:

>
>
> Am Freitag, 24. März 2017 12:42:03 UTC+1 schrieb Andrew Ingram:
>>
>> I've always felt that `is_staff` should be changed to a permission such
>> as `can_access_admin` provided by the Admin app itself.
>>
>
>
>
>> However, `is_superuser` is slightly different, in that it's not a
>> permission, but rather a flag that says "this user has EVERY permission".
>> It's also potentially nonsensical from a functional perspective, you could
>> have two permissions that are intended to be mutually exclusive, but a
>> superuser would nonetheless have both of them - potentially resulting in a
>> broken/nonsense UI.
>>
>
> Thank you for this easy to understand use case. I ask myself if "this user
> has EVERY permission" is needed at all. If the user should have all
> permissions, then why not give
> him all these permissions at database level? It's like a very special 1:N
> relation which is: 1:∞  :-)
>
>
>
>
>
>> This is the main reason why almost nobody should be a superuser (yet
>> nearly every Django project i've inherited has nearly every member of staff
>> marked as superusers).
>>
>>
> Unfortunately we detected this "best practice" too late. We need to switch
> now, but this not related to django-dev, this needs to be solved in our
> company.
>
>
>
>> `is_active` is intended to be used a little differently isn't it? It's
>> not saying "user has no permissions", it's saying "user is disabled". It's
>> not access-control, it's data.
>>
>>
> Let's look at our use case: I want a queryset of all users which have a
> given permission. Do I want to be
> inactive users in this queryset?  I am unsure. But I am sure: I want this
> queryset to be simple at SQL level.
>
>
>
>> I think that most of it could do with a rethink, but `is_staff` is
>> probably the biggest wart.
>>
>> Andy
>>
>>
>>
>
> Thanky you Andy
>
> Regards,
>   Thomas
>
> --
> 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/66dc2010-eca4-409f-9dea-
> f1a4f5aa8217%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/CAFO84S5fJaGgDZpXQLpKd2B9jZCfxBvEqKbjnqWceOf0w1q5hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[guettli]

Am Freitag, 24. März 2017 13:41:10 UTC+1 schrieb Tim Graham:
>
> I don't think the current fields are so bad or nonsensical that it 
> warrants a change. Also, consider that every Django user would have to 
> learn how to use a new permissions setup.
>
> If you don't like the default permissions structure, use a custom user 
> model.
>
>

Yes, I guess we will go this way.

Are there established third party solutions? . I could not find any 
with my favorite search engine ...

Thank you Tim

Regards,
  Thomas
 

-- 
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/945701ea-37d5-4c48-a115-d172edc61ad4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[guettli]

Am Freitag, 24. März 2017 12:42:03 UTC+1 schrieb Andrew Ingram:
>
> I've always felt that `is_staff` should be changed to a permission such as 
> `can_access_admin` provided by the Admin app itself. 
>

 

> However, `is_superuser` is slightly different, in that it's not a 
> permission, but rather a flag that says "this user has EVERY permission". 
> It's also potentially nonsensical from a functional perspective, you could 
> have two permissions that are intended to be mutually exclusive, but a 
> superuser would nonetheless have both of them - potentially resulting in a 
> broken/nonsense UI.
>

Thank you for this easy to understand use case. I ask myself if "this user 
has EVERY permission" is needed at all. If the user should have all 
permissions, then why not give
him all these permissions at database level? It's like a very special 1:N 
relation which is: 1:∞  :-)



 

> This is the main reason why almost nobody should be a superuser (yet 
> nearly every Django project i've inherited has nearly every member of staff 
> marked as superusers).
>
>
Unfortunately we detected this "best practice" too late. We need to switch 
now, but this not related to django-dev, this needs to be solved in our 
company.

 

> `is_active` is intended to be used a little differently isn't it? It's not 
> saying "user has no permissions", it's saying "user is disabled". It's not 
> access-control, it's data.
>
>
Let's look at our use case: I want a queryset of all users which have a 
given permission. Do I want to be
inactive users in this queryset?  I am unsure. But I am sure: I want this 
queryset to be simple at SQL level.

 

> I think that most of it could do with a rethink, but `is_staff` is 
> probably the biggest wart.
>
> Andy
>
>
>

Thanky you Andy

Regards,
  Thomas 

-- 
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/66dc2010-eca4-409f-9dea-f1a4f5aa8217%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[Tim Graham]

I don't think the current fields are so bad or nonsensical that it warrants 
a change. Also, consider that every Django user would have to learn how to 
use a new permissions setup.

If you don't like the default permissions structure, use a custom user 
model.

On Friday, March 24, 2017 at 7:31:32 AM UTC-4, guettli wrote:
>
> I know this is a crazy idea, and it will get the "won't fix" tag very soon.
>
> Nevertheless I want to speak it out.
>
> My use case: Get a queryset of users who have a given permission.
>
> I would like to get this with a simple SQL statement.
>
> At the moment this query is complex and results in performance issues, 
> since
> several outer joins get created. See: 
> https://groups.google.com/forum/#!topic/django-users/lUGkZybXllM
>
> is_superuser and is_staff could be changed to permissions easily.
>
> It's different with is_active. But again: a simple SQL to get all users 
> which have a given permission is my goal.
>
> I personally could live without is_active: Just remove all permissions for 
> this user.
>
> If you don't like dropping all perms to make a user inactive since you 
> want to switch back and forward between active and inactive   ...
> then this a different (bigger) problem: switching back and forward between 
> states. Why not solve
> this for all models (not just User instances)? But this is a different 
> topic :-)
>
> I know the road to deprecate these three friends would be hard since a lot 
> of code uses them.
>
> What do you think?
>
>
>
>
>
>
>

-- 
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/083e3eb0-d76c-4fb7-9f26-ce60ee5f9ef5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[Andrew Ingram]

I've always felt that `is_staff` should be changed to a permission such as
`can_access_admin` provided by the Admin app itself. However,
`is_superuser` is slightly different, in that it's not a permission, but
rather a flag that says "this user has EVERY permission". It's also
potentially nonsensical from a functional perspective, you could have two
permissions that are intended to be mutually exclusive, but a superuser
would nonetheless have both of them - potentially resulting in a
broken/nonsense UI. This is the main reason why almost nobody should be a
superuser (yet nearly every Django project i've inherited has nearly every
member of staff marked as superusers).

`is_active` is intended to be used a little differently isn't it? It's not
saying "user has no permissions", it's saying "user is disabled". It's not
access-control, it's data.

I think that most of it could do with a rethink, but `is_staff` is probably
the biggest wart.

Andy

On Fri, 24 Mar 2017 at 11:31 guettli 
wrote:

> I know this is a crazy idea, and it will get the "won't fix" tag very soon.
>
> Nevertheless I want to speak it out.
>
> My use case: Get a queryset of users who have a given permission.
>
> I would like to get this with a simple SQL statement.
>
> At the moment this query is complex and results in performance issues,
> since
> several outer joins get created. See:
> https://groups.google.com/forum/#!topic/django-users/lUGkZybXllM
>
> is_superuser and is_staff could be changed to permissions easily.
>
> It's different with is_active. But again: a simple SQL to get all users
> which have a given permission is my goal.
>
> I personally could live without is_active: Just remove all permissions for
> this user.
>
> If you don't like dropping all perms to make a user inactive since you
> want to switch back and forward between active and inactive   ...
> then this a different (bigger) problem: switching back and forward between
> states. Why not solve
> this for all models (not just User instances)? But this is a different
> topic :-)
>
> I know the road to deprecate these three friends would be hard since a lot
> of code uses them.
>
> What do you think?
>
>
>
>
>
>
> --
> 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/961fd91c-3954-4c7f-a05e-807f2863dc5e%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/CAOA51CV4KTQHREgQ046nCF2You7kZB407c3jKjgn%3D-%2B0ObREvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Deprecate is_superuser, is_staff and is_active

[guettli]

I know this is a crazy idea, and it will get the "won't fix" tag very soon.

Nevertheless I want to speak it out.

My use case: Get a queryset of users who have a given permission.

I would like to get this with a simple SQL statement.

At the moment this query is complex and results in performance issues, since
several outer joins get created. See: 
https://groups.google.com/forum/#!topic/django-users/lUGkZybXllM

is_superuser and is_staff could be changed to permissions easily.

It's different with is_active. But again: a simple SQL to get all users 
which have a given permission is my goal.

I personally could live without is_active: Just remove all permissions for 
this user.

If you don't like dropping all perms to make a user inactive since you want 
to switch back and forward between active and inactive   ...
then this a different (bigger) problem: switching back and forward between 
states. Why not solve
this for all models (not just User instances)? But this is a different 
topic :-)

I know the road to deprecate these three friends would be hard since a lot 
of code uses them.

What do you think?






-- 
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/961fd91c-3954-4c7f-a05e-807f2863dc5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.