In my Django version I have in `contrib/admin/sites.py` line 371:
has_module_perms = user.has_module_perms(app_label)
https://github.com/django/django/blob/master/django/contrib/admin/sites.py
has_module_perms = model_admin.has_module_permission(request)
https://github.com/django/django/commit/504c89e8008c557a1e83c45535b549f77a3503b2
I think it's clear to me what you are trying to do. By overriding those methods in BarAdmin you go down that line (bypass the django admin permission system), but to get the app listed in the admin index page you would have to actually rewrite the view function. This view function makes an explicit verification on the add/change/delete permissions for the logged in user and app Foo, and as long as your users don't have them granted for such app they can't see it listed.Going back to my concern on overriding the permissions system, have you considered getting the functionality by providing your staff users with permissions at app Foo configuration time? That way your users would get access and you would write less code. You would create a group and would assign permissions to the group. At AppConfig.ready() you could assign your users to the new group, and thus grant them access.Best,DanielOn 07 Oct 2014, at 11:25, Andrea <andrea.ge85@gmail.com> wrote:--I do want that the user is able to add or change some objects. My goal is to bypass the django admin permission system, and overriding "has_*_permission" methods seemed the correct option.I think I was not clear enough in explaining my problem. I will try to rephrase the problem, please tell me if from the first message this point was clear or seemed different.Dear Daniel,thank you for your answer.
The following example is correlated but a bit simpler. Let's suppose I grant the access to all the users to the admin panel (is_staff=True for each user).
Now I want them to be able to add an instance of Bar model.class BarAdmin(admin.ModelAdmin): def has_add_permission(self, request): return TrueIn my opinion that should do the trick, in fact the link to add a new instance is enabled, but it's not shown in the admin index page (and that's my problem).def has_module_permission(self, request): return True
What I do not want to do is to specifically assign the `foo.add_bar` permission under the `permissions` section in the user profile for each user.
Thanks for your time spent in tackling this issue.
Andrea2014-10-07 11:01 GMT+02:00 Daniel Rus Morales <mbox@danir.us>:Hi Andrea,I answer below in between lines.On 07 Oct 2014, at 08:53, Andrea <andrea.ge85@gmail.com> wrote:Let's suppose I have a
Fooapp with aBarmodel with aownerfield. I want a user to be able to edit all the instances for whichobj.owner == request.user.The model appears correctly in the admin panel for superusers and for users for which I have explicitly assigned the permission
change_baroradd_bar, as explained here:Assuming you have an application with an app_label foo and a model named Bar, to test for basic permissions you should use:
add: user.has_perm('foo.add_bar') change: user.has_perm('foo.change_bar') delete: user.has_perm('foo.delete_bar')How can I show the model
Barin the admin index list without explicitly assigningfoo.change_barorfoo.add_barto the user?You can't. The admin interface of Django assumes that when a user has access to the administrative interface of an App-Model it's not to act as a mere passive consumer with read-only access but rather as an active admin over the content (add, change, delete). An administrator who does only inspect or supervise the content doesn't fit in the sort of administrator that the Django administration app allows. It's like allowing an administrator who actually does not administer.So far I tried the following, expecting the
Barmodel to appear in the index list page, but it didn't work.class BarAdmin(admin.ModelAdmin): def get_queryset(self, request): qs = super(BarAdmin, self).get_queryset(request) if request.user.is_superuser: return qs return qs.filter(owner=request.user) def has_add_permission(self, request): return True def has_change_permission(self, request, obj=None): if obj is None: return True if obj.owner == request.user: return True return False def has_delete_permission(self, request, obj=None): if obj is None: return True if obj.owner == request.user: return True return False def has_module_permission(self, request): return TrueAccessing the link
admin/foo/bar/works correctly for every user and returns the list ofBarinstances for whichobj.owner == request.user.admin/foo/bar/addallows the user to add a new object correctly. These links are although not displayed in the admin index page: which is the function that triggers the appearance of the model in the index page?admin/foo/returns403 Forbidden.Uhm… this looks strange to me. So you don't want to provide the user with add/change/delete permissions but you are faking them.The Bar model doesn't appear in the App index list page because the view function in charge first verifies whether the user has any of the add/change/delete permissions granted for such App, and given that your user doesn't have them the App Foo is not listed. In other words, you would have to override the index admin view too (in django.contrib.admin.sites.py), which I don't recommend. Think that by overriding the way permissions are handled in the admin interface you might end up giving change access to regular users that shouldn't have access at all.My recommendation here is to create your own supervising interface for Foo, with its own URLs, to provide the readonly functionality your target users needs. Those users might not probably fall in the category of admins. I'm thinking in maybe managers who need to see what's going on but doesn't have to have write access.Does this answer your questions?I'm using Django 1.7
Thanks,
Andrea
Cheers,Daniel
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAAPQ7Y2DOSaYnScD68Ev-Mh%3D%2B6tH_GMrcKUrDOfsV76fX8OM_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAAPQ7Y2q-RO3FdUjfBd6SLfCNLHE2dX8WVZOSSM-Z5X0d03OCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment