Semantria User Management has changed from individual permissions to group based permissions.
Users no longer are given direct access to specific configurations or projects, instead users are added to groups.
Groups contain the following items:
- Configuration Routes
- Items within a group are visible to every other item in the group.
- Users can be in one or more groups.
- Projects and Configurations can only be in one group.
- A configuration must be in the same group as a project in order to analyze documents in that project.
- Configurations can be moved between groups, but only by admin users.
Admin users are in every group
They cannot be removed from a group, nor can they be given Read Only access to a group.
Only give admin access to users who need it.
When logging into SSV users will now see the Group Selector at the top of the screen next to the time zone.
Clicking on the selector will show the user all the groups they are a part of.
By default all users are a part of the default group, however they can be removed by an admin user if necessary.
Changing your group changes what is visible.
This is true across Configurations, Configuration Routes, Projects and Users.
Projects can only analyze data using configurations that are in the same group.
If a configuration from one group needs to be used to analyze data in a different group we suggest that the configuration is cloned and then the clone can be moved by an admin user to the group where it is needed.
Configurations can be moved between groups, but if the configurations are going to be in heavy use, cloning the configurations is the easier approach.
Within a group users can be All Access or Read Only.
If a user is All Access they can do the following within the group:
- See all configurations
- Use all configurations
- Edit all configurations
- Create configurations
- Delete configurations
- See all non-admin users who are also in the group
- Create projects
- Delete projects
- Edit projects
Within projects in groups All Access users can do anything within a project; add data, delete data, analyze data, create dashboards and edit dashboards.
If a user is Read Only they can do the following within the group:
- See all projects and view their content
- See all configurations and view their content
- See all non-admin users in the group
- Play with widgets in dashboards
None of the changes Read Only users make within a dashboard are saved. Any changes to filters or what is displayed in widgets will not be retained for later access. Read Only users cannot add widgets, they can only edit and play with what is already existing.
Within groups, non-administrators cannot see the Admin users, despite the fact that the admins have access to all groups.
A User can be Read Only in one group and All Access in another group.
Only users with Admin access can edit groups. When an Admin user logs in to SSV and opens the menu they will see the Groups page.
The Groups page shows all the groups in the account on the left hand side of the page. The right hand side shows details for the selected group.
In this example account there are three groups, "Customer Specific Group" "default" and "Tuning Group". This is just an example use of groups and these can be used in any way that a user sees fit.
In the "Customer Specific Group" we see that the users Example Dude and Read Only have Read Only access to the group. The user Power User has All Access.
We can also see that this group has a single configuration and a single project.
Lets look at the default group.
We can see that our Admin user Lexalytics Documentation has removed the user Read Only from the default group. This can be useful if you want to give a customer access to dashboards built off their data but do not want them to be able to see any other accounts or projects, and you don't want them to be able to analyze data or save changes to dashboards.
To delete a user from a group, hover over the user and a trash can icon will appear. The admin will be asked to verify that they want to remove the user from the group.
In this group Example Dude is All Access, note that they had Read Only access in "Customer Specific Group", but All Access in "default". Users do not have to retain access levels across all groups they are in.
On the configurations page admin users can see the additional "Move Configuration" option when hovering over a configuration.
Clicking on this option brings up the move configuration panel where the admin can select which group to move the configuration to.
Configurations that are part of a Configuration Route cannot be moved between groups
To move these they must be removed from the route, or they can be cloned and their clone can be moved to the new group.
Updated 6 months ago