From 1bfffa62a95cf4f7e2a8803f5268aa9b9905d858 Mon Sep 17 00:00:00 2001 From: Oliver Sanders Date: Tue, 22 Aug 2023 15:24:01 +0100 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Ronnie Dutta <61982285+MetRonnie@users.noreply.github.com> --- src/user-guide/sharing-access-to-workflows.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/user-guide/sharing-access-to-workflows.rst b/src/user-guide/sharing-access-to-workflows.rst index 98a61b97637..759b4ecc042 100644 --- a/src/user-guide/sharing-access-to-workflows.rst +++ b/src/user-guide/sharing-access-to-workflows.rst @@ -238,11 +238,11 @@ commands are arranged into groups to avoid having to list them individually: To find out more about a command, see the GraphQL or CLI documentation. -By default, users have ``ALL`` permissions for their own workflows and no -permissions to other users workflows. +By default, users have full permissions (``READ``, ``CONTROL`` and ``ALL``) for their own workflows and no +permissions for other users' workflows. -Permissions are additive, so delegating both ``READ`` and ``CONTROL`` would -provide all permission in both groups. +Permissions are additive, so for example, granting ``READ`` and ``CONTROL`` +would provide all of the permissions from those two groups. The ``!`` character can be used to subtract permissions, e.g. delegating ``CONTROL`` and ``!Stop`` would provide all control permissions except stop. @@ -274,7 +274,7 @@ In this scenario: workflows on the GUI. - ``"group:groupA"`` applies ``CONTROL`` permissions to any member of system ``groupA``. - Note that, since permissions are additive, these users will gain ``READ`` access + Note that, since permissions are inherited, these users will gain ``READ`` access from the ``"*":["READ"]`` assignment. - ``"user1"`` will have permission to view workflows, ``pause`` but not ``play`` workflows, even if ``user1`` is a member of the system ``groupA``. This is due