Remove docs for obsolete register_permissions() hook, refs #2528

Also removed docs for datasette.get_permission() method which no longer exists.

docs/changelog.rst

@@ -26,7 +26,7 @@ Affected plugins should make the following changes:
 
 - Replace calls to ``datasette.permission_allowed()`` with calls to the new :ref:`datasette.allowed() <datasette_allowed>` method. The new method takes a ``resource=`` parameter which should be an instance of a ``Resource`` subclass, as described in the method documentation.
 - The ``permission_allowed()`` plugin hook has been removed in favor of the new :ref:`permission_resources_sql() <plugin_hook_permission_resources_sql>` hook.
-- The ``register_permissions()`` plugni hook has been removed in favor of :ref:`register_actions() <plugin_register_actions>`.
+- The ``register_permissions()`` plugin hook has been removed in favor of :ref:`register_actions() <plugin_register_actions>`.
 
 Plugins can now make use of two new internal methods to help resolve permission checks:
 
@@ -522,7 +522,7 @@ The third Datasette 1.0 alpha release adds upsert support to the JSON API, plus
 See `Datasette 1.0a2: Upserts and finely grained permissions <https://simonwillison.net/2022/Dec/15/datasette-1a2/>`__ for an extended, annotated version of these release notes.
 
 - New ``/db/table/-/upsert`` API, :ref:`documented here <TableUpsertView>`. upsert is an update-or-insert: existing rows will have specified keys updated, but if no row matches the incoming primary key a brand new row will be inserted instead. (:issue:`1878`)
-- New :ref:`plugin_register_permissions` plugin hook. Plugins can now register named permissions, which will then be listed in various interfaces that show available permissions. (:issue:`1940`)
+- New ``register_permissions()`` plugin hook. Plugins can now register named permissions, which will then be listed in various interfaces that show available permissions. (:issue:`1940`)
 - The ``/db/-/create`` API for :ref:`creating a table <TableCreateView>` now accepts ``"ignore": true`` and ``"replace": true`` options when called with the ``"rows"`` property that creates a new table based on an example set of rows. This means the API can be called multiple times with different rows, setting rules for what should happen if a primary key collides with an existing row. (:issue:`1927`)
 - Arbitrary permissions can now be configured at the instance, database and resource (table, SQL view or canned query) level in Datasette's :ref:`metadata` JSON and YAML files. The new ``"permissions"`` key can be used to specify which actors should have which permissions. See :ref:`authentication_permissions_other` for details. (:issue:`1636`)
 - The ``/-/create-token`` page can now be used to create API tokens which are restricted to just a subset of actions, including against specific databases or resources. See :ref:`CreateTokenView` for details. (:issue:`1947`)

docs/internals.rst

@@ -272,14 +272,14 @@ The dictionary keys are the name of the database that is used in the URL - e.g.
 
 All databases are listed, irrespective of user permissions.
 
-.. _datasette_permissions:
+.. _datasette_actions:
 
-.permissions
-------------
+.actions
+--------
 
-Property exposing a dictionary of permissions that have been registered using the :ref:`plugin_register_permissions` plugin hook.
+Property exposing a dictionary of actions that have been registered using the :ref:`plugin_register_actions` plugin hook.
 
-The dictionary keys are the permission names - e.g. ``view-instance`` - and the values are ``Permission()`` objects describing the permission. Here is a :ref:`description of that object <plugin_register_permissions>`.
+The dictionary keys are the action names - e.g. ``view-instance`` - and the values are ``Action()`` objects describing the permission.
 
 .. _datasette_plugin_config:
 
@@ -594,16 +594,6 @@ The following example creates a token that can access ``view-instance`` and ``vi
         },
     )
 
-.. _datasette_get_permission:
-
-.get_permission(name_or_abbr)
------------------------------
-
-``name_or_abbr`` - string
-    The name or abbreviation of the permission to look up, e.g. ``view-table`` or ``vt``.
-
-Returns a :ref:`Permission object <plugin_register_permissions>` representing the permission, or raises a ``KeyError`` if one is not found.
-
 .. _datasette_get_database:
 
 .get_database(name)

docs/plugin_hooks.rst

@@ -777,56 +777,6 @@ The plugin hook can then be used to register the new facet class like this:
     def register_facet_classes():
         return [SpecialFacet]
 
-.. _plugin_register_permissions:
-
-register_permissions(datasette)
--------------------------------
-
-.. note::
-    This hook is deprecated. Use :ref:`plugin_register_actions` instead, which provides a more flexible resource-based permission system.
-
-If your plugin needs to register additional permissions unique to that plugin - ``upload-csvs`` for example - you can return a list of those permissions from this hook.
-
-.. code-block:: python
-
-    from datasette import hookimpl, Permission
-
-
-    @hookimpl
-    def register_permissions(datasette):
-        return [
-            Permission(
-                name="upload-csvs",
-                abbr=None,
-                description="Upload CSV files",
-                takes_database=True,
-                takes_resource=False,
-                default=False,
-            )
-        ]
-
-The fields of the ``Permission`` class are as follows:
-
-``name`` - string
-    The name of the permission, e.g. ``upload-csvs``. This should be unique across all plugins that the user might have installed, so choose carefully.
-
-``abbr`` - string or None
-    An abbreviation of the permission, e.g. ``uc``. This is optional - you can set it to ``None`` if you do not want to pick an abbreviation. Since this needs to be unique across all installed plugins it's best not to specify an abbreviation at all. If an abbreviation is provided it will be used when creating restricted signed API tokens.
-
-``description`` - string or None
-    A human-readable description of what the permission lets you do. Should make sense as the second part of a sentence that starts "A user with this permission can ...".
-
-``takes_database`` - boolean
-    ``True`` if this permission can be granted on a per-database basis, ``False`` if it is only valid at the overall Datasette instance level.
-
-``takes_resource`` - boolean
-    ``True`` if this permission can be granted on a per-resource basis. A resource is a database table, SQL view or :ref:`canned query <canned_queries>`.
-
-``default`` - boolean
-    The default value for this permission if it is not explicitly granted to a user. ``True`` means the permission is granted by default, ``False`` means it is not.
-
-    This should only be ``True`` if you want anonymous users to be able to take this action.
-
 .. _plugin_register_actions:
 
 register_actions(datasette)