Stonefield Query has multiple levels of security.

The first level is login security. If the user does not have a valid user name and password, they cannot log into Stonefield Query and therefore cannot run any reports.

The next set of levels are role-based (roles are referred to as "user groups" in Stonefield Query because users found that easier to comprehend than "roles"). The administrator of a Stonefield Query installation can create users and roles in the Maintain Users and Groups dialog (available from the Tools menu) and assign a user to one or more roles. All users are automatically a member of the Everyone role.

For example, if Mary is a member of both the Administrators and Managers roles, she can access both the Maintain Users and Groups dialog and any reports available only to Managers. If Bob is a member of the Clerks role, he cannot access the Maintain Users and Groups dialog (a user has to be a member of the Administrators role for that) or any reports available only to Managers, but can access any reports available to Everyone and those available only to Clerks.

Roles are used in several ways:

• In the Maintain Users and Groups dialog, an administrator can specify which roles can access certain data groups (this isn't available if you haven't defined any data groups in Stonefield Query Studio). If a role doesn't have rights to a particular data group, none of the users in that role has access to any of the tables in that data group. Those tables won't show up in the report wizards and if the user selects a report containing one of the tables, they get an error message that the report contains tables or fields they do not have access to.

• You can specify which roles have access to certain tables and fields in Stonefield Query Studio. See the Table Properties and Field Properties topics for details. As with data group access, tables and fields the user can't access don't show up in the report wizards and if the user selects a report containing one of the tables or fields, they get an error message that the report contains tables or fields they do not have access to.

• When a report is created or edited, the user can specify which roles have access to the report in the Security Options step of the report wizards. By default, a report is available to the Everyone role, but the user can remove that role and add a different role (such as Managers) to make the report available to only users in that role. If no roles have access to the report, the report is essentially private, available only to its creator. In addition to specifying which roles have access, the user can specify what rights members of the role have: only the ability to run the report or the ability to edit or delete it.

• Similar to reports, when a user creates a folder, they can specify what roles have access to the folder. A user in a role that does not have rights to the folder cannot see the folder or any reports it contains.

If a user is a member of more than one role, their rights are ORed when determining their access to a particular report, folder, table, or field. For example, suppose John is a member of the Managers and Clerks roles. Managers has access to the Payroll table but Clerks does not. Clerks has access to the Products report but Managers does not. In that case, John has access to both the Payroll table and the Products report, since he is a member of roles with access to those items.

Security information is stored in the set of tables described in the Security Tables topic.