Question

I’m not sure if this is a bug or I’m just missing something (although I have already parsed the documentation about inlines), but:

Let’s say I have a model A. Model A is an inline of model B. User U has full access to model B, but only change permissions to model A (so, no add, nor delete).

However, when editing model B, user U can still see the “Add another A” link at the bottom, although U hasn’t add permissions for that respective model.

What’s wrong? Why does that link keep on showing? My logic says that if U does not have permissions to add A, the link shouldn’t appear anymore.

Also, ideally, I would like to give U only view rights to model A (so no add, delete or change – only view), but I’ve read about that (strange, if you ask me) philosophy according to which “If you don’t trust U, just deny him access to the admin area all together”. Kind of a stupid doctrine.

Right now, I’m trying to simulate this ‘view only permissions’ by leaving U with just change rights and set all fields as read only. But I think this is kind of a stupid approach and may also cause problems like the permissions thing above…

How does an average Django programmer like me achieve view-only permissions, and most of all how should I get rid of the “Add another A” link at the bottom of the admin edit form?

Thanks in advance!

Answer 1

If I want a read-only version of what’s in the admin, I just write some normal Django views and keep them out of the admin.

I don’t think the kind of thing you’re talking about (allowing changes to an object but not its inlines) is really supported by the admin. Don’t get me wrong: the admin is very flexible and useful, but it’s not intended to do everything for you.

The only way I see you being able to have this much control in the admin is to not inline A.

“If you don’t trust U, just deny him access to the admin area all together”. Kind of a stupid doctrine.

Not really, when you consider that the admin isn’t intended to have the required level of security hardening to guarantee that fine-grain level of access control. There are many, many places in the admin, due to its open and extensible nature, where bugs can lurk (usually in user-written code) that can be exploited by bad actors. This is why untrusted users should always see all admin URLs return 404.

Anyway, when access control requirements are that fine-grained, it becomes unlikely that a general (i.e. django.contrib) solution will fit.