Current Group Capability

A user has a single Role. A Role gives them access to one or more Production Groups, with their permissions in each group determined by the permission set in the admin. Therefore a user has access to more than one group.

In the desktop client when a user logs in they must choose one of those groups – and that determines which set of preferences the client loads from the server which defines all the preferences for the session – including panels, views, and everything else (proxy settings, path mappings etc. that have nothing much to do with groups, but that is how it has always worked).

In Server 7.3 we have introduced the concept of a current group in the web client, like the desktop client has, but it is not compulsory and you can turn that menu off now.

However , in the web client, the user’s current group is not so all embracing – it only affects two specific things:

1 Visibility rules that are based on the USER’s group (NOT the asset’s group) so Views – yes, Panels – no (goes for the asset’s group). Workspaces – yes.

2 Group based admin Server 7.3 allows non-system admin users access to a cut down version of the admin UI. But they can only access things specific to the group they are allowed to admin, so only non-shared panels, views etc. that have been set up by the system admin. If the user can admin more than one group, then the current group is used to determine which group they are current administering, so it will change what data they see. That is the only case where that is true.