- All references to Pyramid-the-application were changed from :mod:`pyramid`

  to :app:`Pyramid`.  A custom role setting was added to ``docs/conf.py`` to
  allow for this.  (internal)

1 files changed, 7 insertions, 7 deletions

diff --git a/docs/tutorials/wiki2/authorization.rst b/docs/tutorials/wiki2/authorization.rst
index 1691337e9..aaf0f0184 100644
--- a/docs/tutorials/wiki2/authorization.rst
+++ b/docs/tutorials/wiki2/authorization.rst
@@ -9,7 +9,7 @@ view, edit, and add pages to our wiki.  For purposes of demonstration
 we'll change our application to allow only people whom possess a
 specific username (`editor`) to add and edit wiki pages but we'll
 continue allowing anyone with access to the server to view pages.
-:mod:`pyramid` provides facilities for *authorization* and
+:app:`Pyramid` provides facilities for *authorization* and
 *authentication*.  We'll make use of both features to provide security
 to our application.
 
@@ -29,11 +29,11 @@ Adding A Root Factory
 We're going to start to use a custom :term:`root factory` within our
 ``__init__.py`` file.  The objects generated by the root factory will be
 used as the :term:`context` of each request to our application.  In
-order for :mod:`pyramid` declarative security to work properly, the
+order for :app:`Pyramid` declarative security to work properly, the
 context object generated during a request must be decorated with
 security declarations; when we begin to use a custom root factory to
 generate our contexts, we can begin to make use of the declarative
-security features of :mod:`pyramid`.
+security features of :app:`Pyramid`.
 
 We'll modify our ``__init__.py``, passing in a :term:`root factory` to our
 :term:`Configurator` constructor.  We'll point it at a new class we create
@@ -52,7 +52,7 @@ inside our ``models.py`` file.  Add the following statements to your
            self.__dict__.update(request.matchdict)
 
 The ``RootFactory`` class we've just added will be used by
-:mod:`pyramid` to construct a ``context`` object.  The context is
+:app:`Pyramid` to construct a ``context`` object.  The context is
 attached to the request object passed to our view callables as the
 ``context`` attribute.
 
@@ -60,7 +60,7 @@ All of our context objects will possess an ``__acl__`` attribute that
 allows :data:`pyramid.security.Everyone` (a special principal) to
 view all pages, while allowing only a :term:`principal` named
 ``group:editors`` to edit and add pages.  The ``__acl__`` attribute
-attached to a context is interpreted specially by :mod:`pyramid` as
+attached to a context is interpreted specially by :app:`Pyramid` as
 an access control list during view callable execution.  See
 :ref:`assigning_acls` for more information about what an :term:`ACL`
 represents.
@@ -76,7 +76,7 @@ We'll pass the ``RootFactory`` we created in the step above in as the
 Configuring an Authorization Policy
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-For any :mod:`pyramid` application to perform authorization, we need to add a
+For any :app:`Pyramid` application to perform authorization, we need to add a
 ``security.py`` module (we'll do that shortly) and we'll need to change our
 ``__init__.py`` file to add an :term:`authentication policy` and an
 :term:`authorization policy` which uses the ``security.py`` file for a
@@ -87,7 +87,7 @@ We'll change our ``__init__.py`` file to enable an
 declarative security checking.  We'll also change ``__init__.py`` to add a
 :meth:`pyramid.configuration.Configurator.add_view` call to points at our
 ``login`` :term:`view callable`, also known as a :term:`forbidden view`.
-This configures our newly created login view to show up when :mod:`pyramid`
+This configures our newly created login view to show up when :app:`Pyramid`
 detects that a view invocation can not be authorized.  Also, we'll add
 ``view_permission`` arguments with the value ``edit`` to the ``edit_page``
 and ``add_page`` routes.  This indicates that the view callables which these