Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: Ronnie Dutta <61982285+MetRonnie@users.noreply.github.com>
  • Loading branch information
oliver-sanders and MetRonnie authored Aug 22, 2023
1 parent ecdb548 commit edbe4b5
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions src/user-guide/sharing-access-to-workflows.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down

0 comments on commit edbe4b5

Please sign in to comment.