docs: extend group documentation to include information on setting root roles (#3696)

This adds documentation to the RBAC section on how to use root roles on
groups and updates a few screenshots for the group pages.

---------

Co-authored-by: Thomas Heartman <thomas@getunleash.ai>

website/docs/how-to/how-to-create-and-manage-user-groups.md

@@ -20,7 +20,7 @@ This guide takes you through how to use user groups to manage permissions on you
 
 ![The groups screen with the new group button highlighted.](/img/create-ug-step-2.png)
 
-3. Give the group a name and an optional description and select the users you'd like to be in the group.
+3. Give the group a name, an optional description, an optional root role, and select the users you'd like to be in the group.
 
 ![The new group screen with the users drop down open and highlighted.](/img/create-ug-step-3.png)
 

website/docs/reference/rbac.md

@@ -124,7 +124,7 @@ You can assign the following permissions on a per-environment level within the p
 
 :::info availability
 
-User groups are available to Unleash Enterprise users since **Unleash 4.14**.
+User groups are available to Unleash Enterprise users since **Unleash 4.14**. Root role groups are planned to be released in **Unleash 5.1**.
 
 :::
 
@@ -136,10 +136,15 @@ A user group consists of the following:
 - a **description** (optional)
 - a **list of users** (required)
 - a list of SSO groups to sync from (optional)
+- a root role associated with the group (optional) (only available in **Unleash 5.1** and later)
 
-Groups do nothing on their own. They must be given a role on a project to assign permissions. You can assign both standard roles and custom project roles to groups.
+Groups do nothing on their own. They must either be given a root role directly or a role on a project to assign permissions.
 
-While a user can only have one role in a given project, a user may belong to multiple groups, and each of those groups may be given a role on a project. In the case where a given user is given permissions to a project through more than one group, the user will inherit most permissive permissions of all their groups in that project.
+Groups that do not have a root role need to be assigned a role on a project to be useful. You can assign both standard roles and custom project roles to groups.
+
+Groups that *do* have a root role can't be assigned to a project. Any user that is a member of a group with a root role will inherit that root role's permissions globally.
+
+While a user can only have one role in a given project, a user may belong to multiple groups, and each of those groups may be given a role on a project. In the case where a given user is given permissions through more than one group, the user will inherit most permissive permissions of all their groups in that project.
 
 ## User Group SSO Integration
 
@@ -184,4 +189,4 @@ To enable group sync, you'll need to set two fields in your SSO provider configu
 
 Once you've enabled group syncing and set an appropriate path, you'll need to add the SSO group names to the Unleash group. This can be done by navigating to the Unleash group you want to enable sync for and adding the SSO group names to the "SSO group ID/name" property.
 
-[^1]: The project-level permission is still required for the [**create/overwrite variants** (PUT)](/docs/reference/api/unleash/overwrite-feature-variants.api.mdx) and [**update variants** (PATCH)](/docs/reference/api/unleash/patch-feature-variants.api.mdx) API endpoints, but it is not used for anything within the admin UI. The API endpoints have been superseded by the [**create/overwrite environment variants** (PUT)](/docs/reference/api/unleash/overwrite-feature-variants-on-environments.api.mdx) and [**update environment variants** (PATCH)](/docs/reference/api/unleash/patch-environments-feature-variants.api.mdx) endpoints, respectively.
+[^1]: The project-level permission is still required for the [**create/overwrite variants** (PUT)](/docs/reference/api/unleash/overwrite-feature-variants.api.mdx) and [**update variants** (PATCH)](/docs/reference/api/unleash/patch-feature-variants.api.mdx) API endpoints, but it is not used for anything within the admin UI. The API endpoints have been superseded by the [**create/overwrite environment variants** (PUT)](/docs/reference/api/unleash/overwrite-feature-variants-on-environments.api.mdx) and [**update environment variants** (PATCH)](/docs/reference/api/unleash/patch-environments-feature-variants.api.mdx) endpoints, respectively.