All enterprise databases use login security (i.e., they are secure). A standard database can be configured with or without login security (i.e., it may be secure or non-secure). (See Manage Repository Security for instructions on how to determine whether a standard database will have security enabled.)
In a non-secure standard database, any user who has read/write access to the database file (*.rsrp) will have full administrative and user permissions throughout the repository. Security-related features (such as the ability to create a private project or to lock a project) will still be visible in the interface to help you prepare for the transition from a non-secure to secure database, if desired. But the only factor that will prevent any user from performing any function in the repository is whether another user who is simultaneously logged in to the same database has the record currently in use.
In a secure database (both standard and enterprise), the actions that a user can perform in any given project within the repository depend on multiple factors:
Whether the project is public or private.
Whether the user is assigned as the project owner for the project.
For a public project, whether the project uses repository-level or project-level security. In general, we recommend to:
Use repository-level security if you want all projects to be accessible to any user account that is assigned to at least one security group.
Use project-level security if you want different users to have different levels of access for different projects.
The security group(s) that have been assigned to the user account, and the specific permissions associated with each of those groups.
Whether the project is locked.
Whether the project has been checked out.
Whether the project item inherits its item permissions from the project, or can only be edited by a specific subset of the user(s) who are able to edit the rest of the project.
Note: In addition to the factors listed above, the security groups can also be used to assign certain permissions that apply throughout the entire repository (such as the ability to manage user accounts or manage repository time units). If one of these permissions is granted via any of the security groups assigned to the user’s account, he/she will have the capability throughout the entire repository.
In both secure and non-secure databases, the centralized data storage allows multiple users to work collaboratively on analysis projects. Therefore, access to a particular record at any given time will also depend on whether it is currently in use by another user who is simultaneously logged in to the same repository.
© 1992-2013. ReliaSoft Corporation. ALL RIGHTS RESERVED.