Can't disable "add" popup links in the admin

[Jacob]

There's no way to prevent the little green "plus" icons from appearing on related fields in the admin (well, other than removing the related object from the admin). It should be possible to prevent those from appearing -- an admin option would make sense here.

[Ivan Giuliani]

Attached patch adds an exclude_add option (I'm not happy with the naming, any suggestion is welcome) that allows to specify which related fields shouldn't have the add image. Fields should be specified in a list, like exclude_add = [ 'rel_field1', 'rel_field2' ].

However, docs are missing since I'm not a native english-speaker, so it would be nice if someone else could do that.

[Adrian Holovaty]

I like the idea but haven't tested the patch (note there's a print statement in the patch).

[Ivan Giuliani]

Woops, removed the print statement.

[Malcolm Tredinnick]

What's the use-case here? If you have permission to add the object, it's giving you a way to add it. If you don't have permission to add objects of that type, it shouldn't be showing the plus-sign, but I believe that's already the case.

Saying that you can add it in one way, but not in another seems inconsistent.

[fabionatali]

Replying to mtredinnick:

What's the use-case here? If you have permission to add the object, it's giving you a way to add it. If you don't have permission to add objects of that type, it shouldn't be showing the plus-sign, but I believe that's already the case.

Saying that you can add it in one way, but not in another seems inconsistent.

If you have a foreign key with a limit_choices_to filter, then in your admin you get a drop down menu with a selection of items. However, if you add a new item through the green plus link, you can actually circumvent this limit_choices_to filter. You can create a new object which doesn't agree with the limit_choices_to filter and it will be used in the foreign key field despite the filter.

This could be a scenario where disabling the green plus link would make sense.

My 2 cents.

[vincent]

It seems that if you don't have the permission to add objects of a particular type, the add popup link is still there, and there's an ugly Permission Denied page if you click on it.

I tried with Group or User Permissions, and the problem is still there.

There's an old (3 years old) ticket opened here : ​http://code.djangoproject.com/ticket/1035

Another patch a little less old here : ​http://code.djangoproject.com/ticket/2927

But I found no patch for the current version of django.

[milan612]

Hi,

I tried it with latest version of trunk SVN-9218, but doesnt work for me

Any suggestion ?

Milan

[jackymac]

updated patch to so it applies cleanly to SVN-9751, added docs

[jackymac]

I've updated the patch so that it now applies to SVN-9751. Also added some docs. The option is still called "exclude_add." I couldn't think of a better name for it. *shrugs*

I'd be awesome if this could be committed in time for 1.1. Anything I can do to help make that happen?

[Chris Beaven]

Slightly related, I just uploaded a new patch to #1035

[Chris Beaven]

(Sorry, didn't mean to accept the ticket)

[Flo Ledermann]

Btw. you can remove the plus sign by using css - this will not really disable the feature but hide it if you shoot for a more consistent user experience:

#add_id_<<fieldname>> {
    display: none;
}

Best is to look up the id of the element in the admin pages' html source.

If you dont't have an admin css already, you can put this snippet in a file - say css/admin.css - and add a Media class to your Admin class:

    class Media:
        css = {
            'all': [settings.MEDIA_URL + 'css/admin.css']
        }

[Dario Ocles]

I took the idea and I made a new patch. I added a test case that I hope it would be correct and well-done.

[Dario Ocles]

The last patch is obsolete. Updated the patch and adding test case.

[patchhammer]

disable_add_r15922.diff fails to apply cleanly on to trunk

[Dario Ocles]

The patch had a little conflic, I updated the patch to apply to trunk.

[Chris Beaven]

Note that it's actually possible to do this now. Since r13708, the related admin widget has a can_add_related attribute.

Using the ModelAdmin.get_form hook, set this to False for the field(s) you want to disable the plus for.

[Julien Phalip]

#17547 is a duplicate and has a patch.

[atkinsonr@…]

At present this isn't possible in an InlineModelAdmin, however the patch in #17547 looks good as it is to BaseModelAdmin.

[Tim Graham]

Needs a patch that applies cleanly.

[Roger Hunwicks]

For others that end up on this page as the result of a Google Search or similar, as described on ​http://stackoverflow.com/questions/10377642/how-to-use-can-add-related-in-django-admin, the full version of the "Using the ModelAdmin.get_form hook" comment is:

class ProductAdmin(ModelAdmin):

    def get_form(self, request, obj=None, **kwargs):
        """
        Don't allow adding new Product Categories
        """
        form = super(ProductAdmin, self).get_form(request, obj, **kwargs)
        form.base_fields['category'].widget.can_add_related = False
        return form

Given the simplicity of this, do we still need this ticket?

[Claude Paroz]

Closing as per last comment and lack of activity.

[Ryan Castner]

I know this was closed due to inactivity and the ease of doing this, but I feel like the solution, while working and simple is not obvious and requires knowledge of the internals of how the admin works to figure out.

A documented setting to attach to model admin like disable_add_related = ('field_name', ...) seems like it would be a better solution.

The purpose of this is for non-technical admins who should have the ability to add a user but would be confused by the ability to add new users inline while modifying a page, likely if you are creating a new model with a foreign key to 'user' for instance, you don't want to be creating a new user at that time, so displaying the option can only serve to confuse the user

[Tim Graham]

Not every use case can have a ModelAdmin attribute. To keep complexity under control, I think it's better to avoid adding one where an alternative exists.