And again about permission to view

[Григорий Крамаренко]

I understand that the topic was raised repeatedly. It's hard for me to read all the comments, because I badly know English. And I'm not going to talk about permission to view in the admin.

I wrote the ticket, and Tim Graham forwarded me to this mailing list.

I want to say only that unavailability this permission not only brings inconvenience in the development of complex projects. But it is disappointing when you try to make a good and quick accounting system with web interface. In such cases it is necessary to marry a hedgehog and a snake.

In fact, in versions 1.8 and 1.9 it is enough to simply add this functionality without prejudice to existing and new projects. Simple patch, nothing affects, the test passes.

I develop with version 1.3 the accounting system (for hotels and restaurants) and tired to turn themselves inside out when moving from version to version due to the lack of such small things.

Let's make Django better! And not only for building web sites!

[Florian Apolloner]

On Tuesday, July 7, 2015 at 1:30:26 PM UTC+2, Григорий Крамаренко wrote:

In fact, in versions 1.8 and 1.9 it is enough to simply add this functionality without prejudice to existing and new projects. Simple patch, nothing affects, the test passes.

And what about the implications of those changes? Now all of a sudden users without this permission can still view objects in the admin, seems pretty counterintuitive to me…

[Tim Graham]

Since the existing permissions are used in the admin, I don't think adding a view permission that has no effect there would be very intuitive. For projects that do want another permission such as "view" on all its models,  I guess an easy way to do that could be useful.

[Григорий Крамаренко]

Let's get into the admin to check only three permissions in has_module_permissions.

вторник, 7 июля 2015 г., 23:23:12 UTC+10 пользователь Tim Graham написал:

[Григорий Крамаренко]

I look in the code admin.options.BaseModelAdmin.has_module_permission, who regulates access to the admin.
Now any custom permission automatically makes read access to the admin area. So?

среда, 8 июля 2015 г., 0:48:00 UTC+10 пользователь Григорий Крамаренко написал:

[Григорий Крамаренко]

I'm specifically tested with the admin panel.
1. while not included is_staff the user cannot log in admin panel
2. even if you include is_staff and all permissions to view, he still doesn't see anything until he does not has one from next permissions: add/change/delete.

So, as I said at the beginning - this change does not affect the admin panel.

среда, 8 июля 2015 г., 0:54:52 UTC+10 пользователь Григорий Крамаренко написал:

[Florian Apolloner]

On Tuesday, July 7, 2015 at 5:25:38 PM UTC+2, Григорий Крамаренко wrote:

So, as I said at the beginning - this change does not affect the admin panel.

It absolutely does, cause if you assign the "view" permission to a user he should be able to see the changelist, which wouldn't be the case, see https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1447-L1448 -- similar issues would pop up on the app overview etc…

[Григорий Крамаренко]

Whether I don't understand you, or you me.

Permissions in the admin work on the principle of:

access = is_stuff and True in (add_perm, change_perm, delete_perm)

"view" absolutly not affect to the admin panel, just as do not affect to it other custom permissions.
Take a look at this permission as a custom, but installed by default for all models.
Don't think of it as the permissions for the admin.
This permission is for writing business applications or complex web-sites using Django. Using more serious administrative panel than contrib.admin.
Let's write this clearly in the documentation. And just.

P.S.: Who would want to use "view" in contrib.auth - do it youself. It will be very easy.

среда, 8 июля 2015 г., 1:54:53 UTC+10 пользователь Florian Apolloner написал:

[Marc Tamlyn]

A general can_view permission not respected by the admin is not a good idea.

However an easy way to add a general permission to every model in the system in one go would be interesting - a hook into https://github.com/django/django/blob/7da3923ba0c569aa23d0ab0a47a124af60a18f5b/django/contrib/auth/management/__init__.py somehow which allows a couple of lines to add you automatic "can_view", but could also be useful for a general "can_escalate_to_legal", "can_unarchive" or whatever domain specific logic is relevant to most models in a system without having to explicitly add it for every model.

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/39249ee0-b10b-4ee9-b7bb-ee8aac39e374%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Florian Apolloner]

On Wednesday, July 8, 2015 at 6:37:39 AM UTC+2, Григорий Крамаренко wrote:

"view" absolutly not affect to the admin panel, just as do not affect to it other custom permissions.

Yes it does and you are completely ignoring the link I sent -- this would be the first one where not having a check for the view permission.

Don't think of it as the permissions for the admin.

I don't, but the admin has to work with it if we make it a default permission, period. 

 

P.S.: Who would want to use "view" in contrib.auth - do it youself. It will be very easy.

Exactly, it is easy, so do it yourself :þ

[Григорий Крамаренко]

Another variant:

# Add to conf.global_settings.py
...
AUTH_DEFAULT_PERMISSIONS = ('add', 'change', 'delete')
...

# And in db.models.options.py


@python_2_unicode_compatible
class Options(object):
    ...


    def __init__(self, meta, app_label=None):
        ...
        self.default_permissions = settings.AUTH_DEFAULT_PERMISSIONS
        ...

Nothing will change in the distribution. Not default. But will cover my need.

среда, 8 июля 2015 г., 17:03:54 UTC+10 пользователь Florian Apolloner написал:

[Григорий Крамаренко]

I thought of something better:

# Add to conf.global_settings.py
...

CUSTOM_DEFAULT_PERMISSIONS = ()
...

# And add in db.models.options.py

def get_full_default_permissions():
    perms = ['add', 'change', 'delete']
    perms.extend([ x for x in settings.CUSTOM_DEFAULT_PERMISSIONS if not x in perms ])

    return perms

@python_2_unicode_compatible
class Options(object):
    ...


    def __init__(self, meta, app_label=None):
        ...

        self.default_permissions = get_full_default_permissions()
        ...

so, we killed two birds with one stone... ;)


среда, 8 июля 2015 г., 18:02:47 UTC+10 пользователь Григорий Крамаренко написал:

[Tim Graham]

Historically there's been pushback against adding new settings. That said, I don't see an alternative here besides perhaps an AppConfig attribute (last discussed in https://groups.google.com/d/topic/django-developers/qnnCLppwA3o/discussion). Perhaps we should try to move the existing auth settings to the AppConfig and see if that works. I guess it won't be a trivial effort though, and not sure it should block new features like this.

[Григорий Крамаренко]

Then lost the meaning: it is to give the ability to set custom permissions for all third-party applications whose code is "not available".

четверг, 9 июля 2015 г., 21:02:08 UTC+10 пользователь Tim Graham написал: