Re: Contribution in GSOC Django projects

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi Khushi

The wiki page has much information, including many potential projects:
https://code.djangoproject.com/wiki/SummerOfCode2021

Thanks,

Adam

On Sat, 13 Mar 2021 at 09:12, Khushi Kaushal 
wrote:

> Hello!
> I will be participating in Google Summer of code. I wanted to ask about
> the projects and tasks we will be having in this Django Software Foundation
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/59f560c2-0a6f-4a8e-98c3-d4a65a26d611n%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0hvOB9COD-DjrDB3m1vfVN-Pc-92V47BXb0YLPAzD_hw%40mail.gmail.com.

Re: Difference between AdminSite.admin_view and staff_member_required?

[Kevin Grinberg]

`staff_member_required` is a nice convenience method, quite useful outside 
of the admin if your authorization needs are sufficiently served by 
User.is_staff (which isn't always the case of course, but often *is* on a 
small project).

Yes, it can be reduced to a `user_passes_test` call, but that's more 
verbose for a limited gain (given that this convenience method already 
exists, is tested, etc).

Additionally, for a newer developer, getting equivalent functionality 
`user_passes_test` requires being able to grok callables - again, certainly 
something you're going to need past a certain threshold, but it feels 
unnecessary to require less-experienced folks to grok that when all you 
want to do is "make it so that only people with the is_staff attribute can 
see this view" (with the caveat that yes, the login page is going to be the 
admin login page - which for a smaller project is exactly what you want).

On Saturday, March 13, 2021 at 10:03:15 AM UTC-5 pyt...@ian.feete.org wrote:

> I think deprecating it is a good idea. I think it's actually a small 
> footgun - I've seen it used to restrict access to non-admin functionality, 
> when `user_passes_test` would be appropriate. In the case I found it, it 
> made adding tests trickier than it should have been.
>
> Ian
>
> On Tue, 9 Mar 2021 at 21:51, Timothy McCurrach  
> wrote:
>
>> > It seems like a good idea. However, it leads us to another question. Do 
>> we really need the is_staff field on the User Model if it is deprecated?
>>
>> User.is_staff is still used, just from Adminsite.has_permission instead:
>>
>> https://github.com/django/django/blob/main/django/contrib/admin/sites.py#L196
>>
>> On Tue, Mar 9, 2021 at 9:45 PM Matthew Pava  wrote:
>>
>>> > Thoughts on deprecating it? 
>>>
>>> It seems like a good idea. However, it leads us to another question. Do 
>>> we really need the is_staff field on the User Model if it is deprecated?
>>>
>>>  
>>>
>>> *From:* django-d...@googlegroups.com  *On 
>>> Behalf Of *Timothy McCurrach
>>> *Sent:* Tuesday, March 9, 2021 3:22 PM
>>> *To:* django-d...@googlegroups.com
>>> *Subject:* Re: Difference between AdminSite.admin_view and 
>>> staff_member_required?
>>>
>>>  
>>>
>>> staff_member_required feels like a bit of a relic from the past:
>>>
>>> - It looks like before a massive refactor of the admin that happened 12 
>>> years ago (
>>> https://github.com/django/django/commit/a19ed8aea395e8e07164ff7d85bd7dff2f24edca
>>>  
>>> )
>>>  
>>> staff_member_required played a similar role to what Adminsite.admin_view 
>>> does now (checks permissions and redirects to login if appropriate). Before 
>>> the refactor, all of the relevant views were wrapped with 
>>> staff_member_required.
>>> - The above commit introduced AdminSite which has its own 
>>> 'has_permissions' method. Adminsite.root (which was the old get_urls) 
>>> called self.has_permissions before calling any other views, so 
>>> staff_member_required was now no longer really required.
>>> - staff_member_required did however continue to be used in the admindocs 
>>> app (which was now split off into its own app).
>>> - Adminsite.root was eventually replaced with get_urls and the call to 
>>> has_permissions  was moved into `Adminsite.admin_view` (which also does a 
>>> few other things: adds csrf protection, and deals with caching)
>>> - Over time staff_member_required became simpler and simpler as things 
>>> like user_passes_test were introduced, and there was no need to repeat 
>>> logic.
>>> - It's now just a very specific version of `user_passes_test` and is 
>>> only used internally one place - the admindocs app.
>>>
>>>
>>> Tobias - In terms of permissions and redirecting; the behaviour of 
>>> admin_view and `staff_member_required` are very similar. The differences 
>>> are that:
>>>  i) admin_view defers to Adminsite.has_permission to do the actual 
>>> checking of permissions (so if that method is overwritten the behaviour 
>>> will change)
>>>  ii) admin_view does a whole load of other things that all admin views 
>>> are going to need (mentioned above).
>>>  iii) They have slightly different arguments you can pass in to modify 
>>> the behaviour
>>>
>>> If you are decorating a view of ModelAdmin, or AdminSite you should use 
>>> admin_view - as described in the docs under get_urls. 
>>>
>>> Since staff_member_required is more or less a very specific version of 
>>> user_passes_test designed for admin views, it's use-case seems pretty 
>>> niche. If you were making an app like admindocs which behaves like an 
>>> extension of the admin app, without actually being part of the admin app 
>>> you could use it then, but I'm struggling to think of any other time 

Re: Difference between AdminSite.admin_view and staff_member_required?

[Ian Foote]

I think deprecating it is a good idea. I think it's actually a small
footgun - I've seen it used to restrict access to non-admin functionality,
when `user_passes_test` would be appropriate. In the case I found it, it
made adding tests trickier than it should have been.

Ian

On Tue, 9 Mar 2021 at 21:51, Timothy McCurrach 
wrote:

> > It seems like a good idea. However, it leads us to another question. Do
> we really need the is_staff field on the User Model if it is deprecated?
>
> User.is_staff is still used, just from Adminsite.has_permission instead:
>
> https://github.com/django/django/blob/main/django/contrib/admin/sites.py#L196
>
> On Tue, Mar 9, 2021 at 9:45 PM Matthew Pava  wrote:
>
>> > Thoughts on deprecating it?
>>
>> It seems like a good idea. However, it leads us to another question. Do
>> we really need the is_staff field on the User Model if it is deprecated?
>>
>>
>>
>> *From:* django-developers@googlegroups.com <
>> django-developers@googlegroups.com> *On Behalf Of *Timothy McCurrach
>> *Sent:* Tuesday, March 9, 2021 3:22 PM
>> *To:* django-developers@googlegroups.com
>> *Subject:* Re: Difference between AdminSite.admin_view and
>> staff_member_required?
>>
>>
>>
>> staff_member_required feels like a bit of a relic from the past:
>>
>> - It looks like before a massive refactor of the admin that happened 12
>> years ago (
>> https://github.com/django/django/commit/a19ed8aea395e8e07164ff7d85bd7dff2f24edca
>> )
>> staff_member_required played a similar role to what Adminsite.admin_view
>> does now (checks permissions and redirects to login if appropriate). Before
>> the refactor, all of the relevant views were wrapped with
>> staff_member_required.
>> - The above commit introduced AdminSite which has its own
>> 'has_permissions' method. Adminsite.root (which was the old get_urls)
>> called self.has_permissions before calling any other views, so
>> staff_member_required was now no longer really required.
>> - staff_member_required did however continue to be used in the admindocs
>> app (which was now split off into its own app).
>> - Adminsite.root was eventually replaced with get_urls and the call to
>> has_permissions  was moved into `Adminsite.admin_view` (which also does a
>> few other things: adds csrf protection, and deals with caching)
>> - Over time staff_member_required became simpler and simpler as things
>> like user_passes_test were introduced, and there was no need to repeat
>> logic.
>> - It's now just a very specific version of `user_passes_test` and is only
>> used internally one place - the admindocs app.
>>
>>
>> Tobias - In terms of permissions and redirecting; the behaviour of
>> admin_view and `staff_member_required` are very similar. The differences
>> are that:
>>  i) admin_view defers to Adminsite.has_permission to do the actual
>> checking of permissions (so if that method is overwritten the behaviour
>> will change)
>>  ii) admin_view does a whole load of other things that all admin views
>> are going to need (mentioned above).
>>  iii) They have slightly different arguments you can pass in to modify
>> the behaviour
>>
>> If you are decorating a view of ModelAdmin, or AdminSite you should use
>> admin_view - as described in the docs under get_urls.
>>
>> Since staff_member_required is more or less a very specific version of
>> user_passes_test designed for admin views, it's use-case seems pretty
>> niche. If you were making an app like admindocs which behaves like an
>> extension of the admin app, without actually being part of the admin app
>> you could use it then, but I'm struggling to think of any other time you
>> would want to use it though.
>>
>> I think there's an argument to be made for deprecating it completely:
>>  - It's only used in one place internally, and the wider use case seems
>> pretty niche.
>>  - user_passes_test can do the same thing and seems to be the standard
>> way of doing this kind of thing anyway.
>>  - user_passes_test with a suitably named test argument would also be
>> more explicit, since the login_url and redirect_field_name would need to be
>> explicitly stated.
>>
>>  Definitely the documentation should be updated though. Thoughts on
>> deprecating it?
>>
>> Tim
>>
>>
>>
>> On Tue, Mar 9, 2021 at 7:08 PM Tobias Bengfort 
>> wrote:
>>
>> On 09/03/2021 18.03, Carlton Gibson wrote:
>> > Do you want to open a PR with suggested changes as a focus for
>> discussion?
>>
>> I would open a PR that improves the docs, but I still don't understand
>> the difference, so I wouldn't know what to write.
>>
>> The other alternative would be remove one of them, but at this point
>> that is probably too drastic.
>>
>> tobias
>>
>> --
>> You received this message 

Contribution in GSOC Django projects

[Khushi Kaushal]

Hello!
I will be participating in Google Summer of code. I wanted to ask about the 
projects and tasks we will be having in this Django Software Foundation

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/59f560c2-0a6f-4a8e-98c3-d4a65a26d611n%40googlegroups.com.