8

Is there a way to remove the "Add" functionality on the Django admin site? For certain entities, I only want the Django admin to be able to view them or change existing ones, but not add new ones.

Krystian Cybulski
  • 10,789
  • 12
  • 67
  • 98

6 Answers6

8

See: Django Admin - Disable the 'Add' action for a specific model for true solution.

Community
  • 1
  • 1
Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
3

Sure, you can customize admin VERY granularly by following the instructions here -- I believe that what you want can be obtained in part by overriding ModelAdmin.save_model(self, request, obj, form, change) in your own ModelAdmin subclass, to ensure nothing happens on the store when change is false (i.e. an attempt to add rather than change), and in part by overriding ModelAdmin.add_view(self, request, form_url='', extra_context=None) to display an "add view" that makes it very clear to the admin that they're NOT going to be allowed to add object through this route. I haven't actually done the specific admin customization you require, but I've done others and they do seem to work pretty smoothly!

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
  • Thank you for the answer. I was hoping for a setting which would accomplish this, the way the save_as ModelAdmin property works. – Krystian Cybulski Aug 02 '09 at 02:06
  • I'm not aware of such settings in stock Django 1.0, but maybe there's some >1.0 and/or contrib hack to supply it -- stock 1.0.something is what I've stuck with so far (mostly because it runs fine on app engine, I confess;-). – Alex Martelli Aug 02 '09 at 02:47
  • 1
    This answer overcomplicates things. Removing the users Add Permission does the trick perfectly for the situation you've described. (That is assuming you only need to control it per model and not per instance.) – Andy Baker Aug 03 '09 at 00:04
  • @andibak, the admin normally can edit users, and so in particular can change permissions, including their own. What's your plan for dealing with that, without subclassing ModelAdmin and thus essentially equaling the complications of what you claim is my overcomplicated answer?-) – Alex Martelli Aug 03 '09 at 00:27
  • @krys: Could you clarify whether the users in question could potentially need to administer user permissions as well? This is for posterity: Your initial question has already been answered by @alex, but others may come across this question and get some guidance from your response. Thanks! – anschauung Aug 04 '09 at 22:42
  • @Alex Martelli We have a different understanding of the original question. I didn't interprete that the reference to 'the Django admin' as meaning a specific superuser. – Andy Baker Nov 28 '09 at 21:38
3

You can customize the permission for each user group from within the admin interface: try going to /admin/auth/group and it should be straightforward from there.

This won't be as granular as the solution offered by the earlier answer, but it will take care of most of your needs without needing to customize the admin.

anschauung
  • 3,697
  • 3
  • 24
  • 34
  • 2
    But as the OP specifically wants to block *the admin* from doing certain things, as the question so clearly states, how is he going to block the admin from just undoing the permission changes (esp. if he does want to allow the admin to DO some administering;-)? – Alex Martelli Aug 03 '09 at 00:30
  • @Alex: This is true -- I meant my response as a simpler alternative to your response, but simplicity comes with limitations of course. – anschauung Aug 03 '09 at 11:33
2

If you change the permissions to restrict access then you'll still get the plus sign by a FK/MtM field. Clicking that will open a popup window with 'Permission Denied' in it.

You can actually completely remove the plus sign by not simply not registering the model with the admin.

I have a situation where I have predefined categories that I want users to be able to select more than one of. The best way to do this is with a models.ManyToMany field. You can register the model with the admin, enter the data as required and then remove the registration.

Tim Fletcher
  • 21
  • 1
1

An easy effective way is to set max_num=0 for that particular inline.

PeeHaa
  • 71,436
  • 58
  • 190
  • 262
EyalItskovits
  • 116
  • 1
  • 9
0

Satya's suggestion of setting max_num=0 works perfectly.

Per the Django docs on the ModelForm class:

For users with JavaScript-enabled browsers, an "Add another" link is provided to enable any number of additional inlines to be added in addition to those provided as a result of the extra argument.

The dynamic link will not appear if the number of currently displayed forms exceeds max_num, or if the user does not have JavaScript enabled.

and

As with regular formsets, you can use the max_num and extra parameters to modelformset_factory to limit the number of extra forms displayed.

max_num does not prevent existing objects from being displayed

Eli Burke
  • 2,729
  • 27
  • 25