From 3796d312e30406114c35333fe0b773d68cc5b721 Mon Sep 17 00:00:00 2001
From: Daniel Greenfeld <pydanny@gmail.com>
Date: Sat, 6 Jul 2013 11:18:38 +0200
Subject: [PATCH] Add index links for permissions

---
 docs/ref/permissions.rst | 32 ++++++++++++++++++++++++++------
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/docs/ref/permissions.rst b/docs/ref/permissions.rst
index 4d0b106..5b11403 100644
--- a/docs/ref/permissions.rst
+++ b/docs/ref/permissions.rst
@@ -1,6 +1,8 @@
 Permissions
 ===========
 
+.. index:: Permissions
+
 Permissions are handled on a per view basis. So basically each admin view can
 hold its own permissions. That way you are very flexible in defining
 who is allowed to access which view. For example, the edit view might need some
@@ -28,8 +30,11 @@ attribute:
 See the following sections on which permission classes ship with
 **django-admin2**, ready to use and how you can roll your own.
 
-Builtin permission classes
---------------------------
+Built-in permission classes
+---------------------------
+
+.. index::
+    single: Permissions; Built-In Permission Classes
 
 You can use the following permission classes directly in you views.
 
@@ -48,6 +53,9 @@ You can use the following permission classes directly in you views.
 Writing your own permission class
 ---------------------------------
 
+.. index::
+    single: Permissions; Custom Permission Classes
+
 If you need it, writing your own permission class is really easy. You just need
 to subclass the :class:`djadmin2.permissions.BasePermission` class and
 overwrite the :meth:`~djadmin2.permissions.BasePermission.has_permission`
@@ -89,9 +97,12 @@ Here is an example implementation of a custom permission class:
                     return False
             return True
 
-Permissions in templates
+Permissions in Templates
 ------------------------
 
+.. index::
+    single: Permissions; Permissions in Templates
+
 Since the permission handling is designed around views, the permission checks
 in the template will also always access a view and return either ``True`` or
 ``False`` if the user has access to the given view. There is a ``{{ permissions
@@ -128,9 +139,12 @@ At the moment we can check for the following four basic permissions:
 ``has_delete_permission``
     This will check the permissions against the current admin's ``delete_view``.
 
-Object-level permissions
+Object-Level Permissions
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. index::
+    single: Permissions; Object-Level Permissions
+
 The permission handling in templates also support checking for object-level
 permissions. To do so, you can use the ``for_object`` filter implemented in the
 ``admin2_tags`` templatetag library:
@@ -181,9 +195,12 @@ permissions as well:
         {% include "list_of_model_actions.html" with permissions=object_permissions %}
     {% endwith %}
 
-Checking for permissions on other models
+Checking for Permissions on Other Models
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. index::
+    single: Permissions; Checking for Permissions on Other Models
+
 Sometimes you just need to check the permissions for that particular model. In
 that case, you can access its permissions like this:
 
@@ -214,9 +231,12 @@ to a model admin, you can use the ``for_admin`` filter:
         {% endwith %}
     {% endfor %}
 
-Dynamically check for a specific permission name
+Dynamically Check for a Specific Permission Name
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. index::
+    single: Permissions; Dynamically Check for a Specific Permission Name
+
 Just like you can bind a permission dynamically to a model admin, you can also
 specify the actual permission name on the fly. There is the ``for_view`` filter
 to do so.