Add "view" permission to compliment add/change/delete

[kayos@…]

This small patch adds a "view" permission to compliment the add/change/delete permissions. A user with this permission will be able to see the admin display_list for an object (django.contrib.admin.views.main.change_list).

It doesn't implement a view_stage(). It would be less trivial to add a sort of read-only version of change_stage/add_stage.

One use case for this feature would be letting users see a list of objects even though they couldn't change them. Another would be letting a user who has add permission (but not change or delete) to see that their object got added.

[Jacob]

This is out of the scope of the admin (you can easily use a generic view on the public site, or use a very simple custom view inside the admin).

[jacmkno]

Why is it out of the scope? I think it couldn't be more on the scope.
This feature is an extremely common requirement for any kind of information management application.
If it is that simple, Django should come with a view only permission by default.
I think this should be discussed a little bit more before being disregarded.

[gunzip]

I know there has been a long thread around this. These words, which are not mine, summarize it well:

"""There are workarounds, but this is going to surface in more and more projects.
Lets get a solution for this (whatever it is) and implement it in Django instead of everybody implementing workarounds"""

Moreover this workarounds are not documented. I still don't know how to cope with the well know issue with
"raw_id" change_list popup (that still needs CHANGE rights on the target model).

Let's face this: at the current (amazing) level of customization the "admin" interface serves not only "admin" users.
It's frustrating to be answered "write your own admin backend from scratch if you need view permissions".

I guess probably 99% of current django users needs this functionality more than before, please consider to reopen this.

[ben@…]

I couldnt agree more. I have been a happy django convert for the last 4 months. I just started writing a very basic document library area into the admin area. Logging in as admin i can add, delete and change a file in the list. Next step... add a test user to represent a member of staff that is able to view any document uploaded, but is unable to add their own. To my absolute surprise there are no view permissions to be found.

I think it is ridiculous that this feature is being disregarded as a 'non admin' issue.

[Russell Keith-Magee]

The Admin site is, as the name suggests, for _administration_. As Jacob noted, It isn't intended to be the public facing part of your website.

As a matter of process, if you disagree with a wontfix decision from one of the core team, you don't just reopen the ticket - you start a discussion on Django developers.

[naktinis@…]

We need view permissions also because we have different levels of admins. So we want to be able to say: user A can modify field X on this model and read all other fields, user B can modify fields X and Y and read X, Y, and Z etc. Does having customizable permissions (admin levels) really not make sense?

[anonymous]

I'd really like to see this done! I want to give readonly admin accounts to interns, designers, developers, sales reps and sales prospects, because I want them to be able to see the admin interface of a live system.

[anonymous]

4 shizzle

[Mike Lissner]

I'd like to see this too. We have interns that need to do development, but since our data is so complex, it's difficult for them to get a good sample database set up on their development machine. If they could simply peek into the live system it'd be very valuable. I was looking at the deprecation notes for the dataview module, and they suggested that we might add its functionality to admin. Would be great to get that idea going again. Seems to be a fairly simple and often requested feature.

[Tim Graham]

#8936 is the open ticket for adding databrowse-like functionality to the admin. This ticket is closed.

[Tim Graham]

This is fixed in #8936 so changing resolution to "duplicate" rather than "wontfix".