I think I've found the problem. In my Django version I have in `contrib/admin/sites.py` line 371:
has_module_perms = user.has_module_perms(app_label) Here it is instead: https://github.com/django/django/blob/master/django/contrib/admin/sites.py line 383: has_module_perms = model_admin.has_module_permission(request) I was probably reading the dev documentation of something that's not in Django 1.7 but will be in Django 1.8. https://github.com/django/django/commit/504c89e8008c557a1e83c45535b549f77a3503b2 Thanks! Andrea 2014-10-07 11:54 GMT+02:00 Daniel Rus Morales <[email protected]>: > 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, > Daniel > > > On 07 Oct 2014, at 11:25, Andrea <[email protected]> wrote: > > Dear Daniel, > > thank you for your answer. > 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. > > 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. > > 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 True > > def has_module_permission(self, request): > return True > > In 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). > 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. > > Andrea > > 2014-10-07 11:01 GMT+02:00 Daniel Rus Morales <[email protected]>: > >> Hi Andrea, >> >> I answer below in between lines. >> >> On 07 Oct 2014, at 08:53, Andrea <[email protected]> wrote: >> >> Let's suppose I have a Foo app with a Bar model with a owner field. I >> want a user to be able to edit all the instances for which obj.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_bar or >> add_bar, as explained here >> <https://docs.djangoproject.com/en/dev/topics/auth/default/#topic-authorization> >> : >> >> 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 Bar in the admin index list without explicitly >> assigning foo.change_bar or foo.add_bar to 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 Bar model 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 True >> >> Accessing the link admin/foo/bar/ works correctly for every user and >> returns the list of Bar instances for which obj.owner == request.user. >> admin/foo/bar/add allows 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/ returns 403 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 [email protected]. > To post to this group, send email to [email protected]. > 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 > <https://groups.google.com/d/msgid/django-users/CAAPQ7Y2DOSaYnScD68Ev-Mh%3D%2B6tH_GMrcKUrDOfsV76fX8OM_g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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 [email protected]. To post to this group, send email to [email protected]. 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.
