Members Manager can be access from the System Managers section of the main menu on the Administration tab:
Members are only needed on a Multi-User installation.
Single User Installation
A single user system only has an administrator. Administrators can create published views for other employees in an organization to use with external reporting tools.
This style of installation is analogous to a traditional IT department controlling all aspects of user data access. IT manually builds and manages database views for employees to use.
Although, DSF makes managing and creating database views very easy for the IT administrator, having only one user it is not the preferred DSF installation method. Single user makes the administrator the bottle neck for employees to access the data they need in timely manner.
Many clients start with this method during the trial period but ultimately switch to a Multi-User installation to allow users the ability to self-serve their own data fields.
Multi-User Installation (Preferred)
Administrators must create a member in a DSF database for any employee wishing to access the system.
ALL members MUST have a valid Activation Code when logging into the system. Just being setup as a member DOES NOT grant access. They must also have valid database READ credentials to access the physical databases they will be connecting to.
DSF links the activation code's email address to the email address provided by the administrator when creating the member. Both must match for access to be granted.
Data Teams or Security Roles can be used to control data access when running with an Enterprise User license.
Members added to a Data Source do not necessarily have to be a member of a Security Role.
Members given administrative rights will have access to ALL objects the same as the creator of the Data Source.
Standard Viewer User licenses CANNOT be made administrators. Only a Professional or Enterprise User licenses can be administrators.
Non-administrator users will not have any access to data unless they are members of a Security Role.
If you have multiple users but are not implementing Security Roles the members MUST still be members of the Default role.
The DSF security system errors on the side of caution, therefore, data access MUST be granted to a non-administrator user through the use of a Security Role.
To make a member an administrator check the Administrator box on the member detail screen.
Detail
Create New Member
LDAP Members
A distributed network environment referred to as Active Directory, LDAP (Lightweight Data Access Protocol) and the like, stores network user information in a database.
Sometimes it is possible for DSF to read this information to aid in adding members to the system. This is simply an aid that will attempt to extract the information from Active Directory and fill the form.
When available, it's best to use the provided network information when creating a new member.
Name
Use a unique display name to describe the user.
Email Address
It’s imperative that this email address matches the registered DSF activation code as provided by Data Selections. If this email does not match the activation code, access will be denied for this user. This field is NOT case sensitive.
Security Identifier (SID)
Any unique identifier for the user. LDAP will assign a value like (S-1-5-21-1814550740-8088145109-1701926050-4556) however, if you are not using the LDAP aid just enter any value that uniquely identifies a user. (1,2,3…)
Administrator
Checking this box will give this user the same full access rights as the Data Source creator. Administrators cannot be denied access and are not bound by any Security Roles they may be members of. This is similar to a Systems Administrator (SA) of a database.
Extended Information
This will display any extended information found during an Active Directory search. For those familiar, it will return CN, OU and DC values pertaining to the selected user.
View Publish Options
Publish options are not a requirement. However, in an enterprise environment the DBA may want to organize the publishing of database views by users into a specific Schema in the database (DSF_VIEWS). If a more detailed breakdown is required, they can separate the users into individual Schemas. Using Schemas and setting View Create permissions in a database is beyond the scope of this document.
Schema Name
When publishing, the view will be created in this Schema for the user.
Prefix
If publishing to a common Schema the prefix will separate the view names by user or group within the Schema.
Schema Binding
Only enable schema binding if you know what it's used for and need it for your organization. When a view is created in MSSQL the Schema binding option prevents any base tables from being modified in a way that would affect the view definition. The view definition would need to be deleted to remove the dependencies on the table to be modified. Most of the time this option is more trouble than it’s worth and is only included for those who need it.