Add a way to register a model with the admin but prevent it from appearing on the app index page

[kace]

I have come upon an interesting use case that I believe would benefit from a new option. I have a model that is normally administered underneath another model via a TabularInline arrangement. However, this model may also be a foreign key option to other models. When going to the admin page of these other models, the normal "+" sign graphic to add a model is not present (which makes sense, as it is not registered independently with the admin). However, I need the "+" sign add option to appear, but also want the object to not appear in the main index by itself -- because it should be administered via the TabularInline's underneath its normal parent object and two standard paths to the same object cause user confusion.

(There is more detail here:
​http://groups.google.com/group/django-users/browse_thread/thread/99f90b66e24cfa60 .)

The patch I propose and attach is against Django version 1.2.5. It adds an option "no_index" to the models' meta class which causes an independently registered model to not appear in the main index or app index. (The patch is functional, but not pretty. If the use case and feature are deemed valuable, it might be implemented in a better way. (E.g., it only checks for the presence of "no_index" and ignores the value.))

[kace]

small patch for "no_index" meta option

[kace]

As regards solutions, let me add that the place I was looking and hoping for a solution was as an option to the "admin.site.register()" function. With something like "admin.site.register(kids, no_index=True)", for example. That would be much more appropriate since it's an admin issue, not a model issue. I just didn't have time to pursue an ideal solution. Thanks.

[kace]

improved patch for ModelAdmin option "no_index"

[kace]

I just attached a new patch that implements in a cleaner way. Only touches "django/contrib/admin/sites.py" and "django/contrib/admin/options.py" and changes/adds three lines of code. Could be easily ported to other versions I think. To suppress indexing, one adds the option "no_index=True" to the "admin.site.register" function (as proposed in previous comment).

[anonymous]

I created docs and tests for this, and made it so no_index would also exclude it's ModelAdmin from the app-level index as well.

Here is the pull request: ​https://github.com/django/django/pull/107/files

Please let me know if I did the tests wrong or something.

[samuraiblog@…]

Replying to anonymous:

I created docs and tests for this, and made it so no_index would also exclude it's ModelAdmin from the app-level index as well.

Here is the pull request: ​https://github.com/django/django/pull/107/files

Please let me know if I did the tests wrong or something.

[Julien Phalip]

Thank you all for your work on this ticket.

While I understand and appreciate the need for excluding certain models from the general index and app indexes, I'm not sold on the suggested approach. The long-term goal for the admin is to provide more flexibility around the admin's structure and workflows, and adding a 'no_index' option would tie ModelAdmin to the idea that an index would systematically be part of the structure.

On this basis, I'm going to reject the current pull request.

The index functionality is currently already tied to contrib.admin.sites.AdminSite. It should already be possible to exclude models from the index by overriding the index() and app_index() methods, although I admit it probably wouldn't be pretty. A new API could be designed to make it prettier and easier, but I believe that should be done in AdminSite, not ModelAdmin.

[Collin Anderson]

I personally use this workaround, but it's undocumented:

    def get_model_perms(self, request):
        return {}

[Tim McCurrach]

This is already solved by has_module_permission. From the docs:

"Should return True if displaying the module on the admin index page and accessing the module’s index page is permitted, False otherwise. Uses User.has_module_perms() by default. Overriding it does not restrict access to the view, add, change, or delete views..."

Unless there's something I'm missing, this ticket can be closed.

[Mariusz Felisiak]

Tim thanks for pointing this out. We can close it as a duplicate of #6327.

Fixed in 504c89e8008c557a1e83c45535b549f77a3503b2.