There's more to experience when you log in!
Access control settings work in conjunction with roles to define the permissions for a user. Roles define the permissions for categories of entities, such as all dataflows or all database resources, and access control settings define the permissions for specific entities, such as specific jobs or specific database connections.
To configure access control:
The secured entities you chose are displayed. The check boxes indicate the permissions in effect for the selected role or user.
Hi Abdul, Nalin,
For the 2018.2 version of SSA and Spectrum there is no need to set permissions in Spectrum Management Console. Management Console should only be used for the creation of users and roles and assignment of users to roles.
For SSA projects all permission management is performed in SSA itself by granting role permissions to map projects, and optionally you can grant extra permissions in Spectrum Spatial Manager to allow users to edit data or browse and add additional maps or layers to their projects.
Setting secured Location Intelligence secured entity overrides in Management Console will break the permissions that SSA and Spectrum Spatial manages. We plan to remove the pages in Management Console for Location Intelligence permissions so that they are no longer available.
I have provided an overview below as this is an area that is difficult to understand as a newbie. Please let me know if you need further details on any aspect.
The steps can broadly be broken into 3 as follows:
Logged in as admin in Management Console, create a role (for example AnalystEditorRole) and a user (for example PlanningUpdateUser), and assign the user to the AnalystEditorRole. Roles must start with the word "Analyst" if you want them to be available in SSA (we may remove this limitation in future)
Logged in as admin in SSA, create a map project (for example PlanningProject) that references various named maps and layers from Spectrum. On the project settings panel under permissions pick from the available roles and add them to the project.
Below I have given 3 roles including the AnalystEditorRole read access to my "PlanningProject".For most use cases this is all you need to do. Any user who belongs to these 3 roles will be able to open the map project (but not edit data, I will cover the editing case further down as step 3)
When you save the project SSA will
In Spectrum Spatial Manager you can see the permissions granted by SSA to the named maps, layers and tables under the permissions section. Below is an image showing layer permissions all of which have been set by SSA to the AnalystEditorRole
As an SSA customer you do not normally need to modify these permissions for read access. You should not normally remove them as it may break an SSA project (but you can remove them if there are no active SSA projects using those resources).
You can also grant additional read access to other name layers (which are not in and SSA projects) here if desired. An SSA user will then be able to browse and add those layers to an SSA project themselves if that functionality is enabled in the project.
SSA and Spectrum Spatial support end user editing of tables (both geometry and attribute data)
To allow a user to edit data in a named table you do need to give them (or ideally a roe they belong to) extra permissions in Spectrum Spatial Manager as a prerequisite.
This is done on the "permissions" - "resource permissions" page in the "tables" tab. You can specify Insert, Update and Delete permissions. If the table is already referenced by a layer in a project that you have granted read permissions on, then it should appear in the list with read access already. If not, you can add the table and then grant the project permissions later.
Once these permissions are given, and if the SSA project has enabled the editing functionality (in the functionality profile used by the project), then the user who belongs to the role will be able add, modify and delete individual records (features) in SSA.
Below I have given the AnalystEditorRole ability to perform any editing on the SQL server planning applications table. Any user who belongs to this role can edit this table if the SSA project allows editing. If a user who is in one of the other roles opens the same project (say the user in the AnalystTrainingRole) then they wont be given the ability to edit the data.And below my user who belongs to the AnallystEdtorRole is in edit mode.
Allowing other users to create and manage SSA projects.
Currently for SSA 2018.2 only the admin user can create new projects and grant permissions on them. The project settings option in SSA is not available to any other users.
In the upcoming release 2019.1 we are also supporting the concept of sub-admins in SSA. It will be possible for admins to designate other users as sub-admins and to give them write access to specific folders in the spectrum repository. This concept is already available for Spectrum now but is not exposed to SSA. From 2019.1 sub-admins will also be able to create map projects, save them and also grant read permissions on them to other users.
We are also integrating SSA permission management into Spatial Manager as well, so that can manage and see all relevant permissions for projects as well as maps, layers and tables.
Hierarchy of projects, maps and permissions.
When working with permissions it is useful to picture the following hierarchy.
Permissions are propagated from the higher level to the lower level. So, setting read permission in SSA on a project propagates those permissions to maps, layers and tables
Setting permission on a named layer in Spatial Manager will propagate that permission to the named table (this default behaviour can be disabled, but is required when using SSA.
Users vs roles
Finally, it is worth mentioning that for SSA you can only grant permissions to roles. Users who belong to that role inherit the role's permissions. A user can belong to many roles and they get the collective permissions of all those roles.
In Spatial manager it is also possible to grant permissions to users as well. This is not needed for SSA since a user gets all the read permissions, they need through the prorogation of the project permissions. We recommend setting permissions only to roles for simplicity, however for certain circumstances (say edit permissions) you could set permissions to only users if required.
The relevant docs are here
Managing users and roles in Management Console
Setting permissions on SSA projects
Permission management in Spectrum Spatial (overview and using spatial manager)