docs: add EditorRestricted role release note (#9007)

docs/manage/security/rbac.rst

@@ -475,6 +475,12 @@ edit, or delete projects and experiments within its scope.
 The ``Editor`` role supersedes the ``EditorRestricted`` role and includes permissions to create or
 update NTSC tasks within its scope.
 
+-  ``EditorRestricted`` users can still open and use scoped JupyterLab notebooks and perform all
+   experiment-related jobs, just like those with the ``Editor`` role. The only additional
+   permissions granted by the ``Editor`` role include the ability to create notebooks, TensorBoards,
+   shells, and commands (NTSC tasks), as well as the permission to update these tasks, such as
+   changing the task's priority or deleting it.
+
 ``WorkspaceAdmin``
 ==================
 

docs/release-notes/editor-restricted-role.rst

@@ -0,0 +1,22 @@
+:orphan:
+
+**New Features**
+
+-  RBAC: Add a pre-canned role called ``EditorRestricted`` which supersedes the ``Viewer`` role and
+   precedes the ``Editor`` role.
+
+   -  Like the ``Editor`` role, the ``EditorRestricted`` role grants the permissions to create,
+      edit, or delete projects and experiments within its designated scope. However, the
+      ``EditorRestricted`` role lacks the permissions to create or update NTSC-type workloads.
+
+      Therefore, a user with ``EditorRestricted`` privileges in a given scope is limited when using
+      the WebUI within that scope since the option to launch JupyterLab notebooks and kill running
+      tasks will be unavailable. The user will also be unable to run CLI commands that create scoped
+      notebooks, TensorBoards, shells, and commands and will be unable to perform updates on these
+      tasks (such as changing the task's priority or deleting it). ``EditorRestricted`` users can
+      still open and use scoped JupyterLab notebooks and perform all experiment-related jobs, just
+      like those with the ``Editor`` role.
+
+   -  The ``EditorRestricted`` role allows workspace and cluster editors and admins to have more
+      fine-grained control over GPU resources. Thus, users with this role lack the ability to launch
+      or modify tasks that indefinitely consume slot-requesting resources within a given scope.