Global groups are groups that are built into LabKey Server and which have configurable permissions for every project. The global groups can be accessed by site admins via (Admin) > Site > Site Groups
The Site Administrators Group
The Site Administrators group includes all users who have been added as global administrators. Site administrators have access to every resource on the LabKey site, with a few limited special use exceptions. Only users who require these global administrative privileges should be added to the Site Administrators group. A project administrator
requires a similarly high level of administrative access, but only to a particular project, and should be part of the Site Users group, described below
and then added to the administrators group at the project level only.
All LabKey security begins with the first site administrator, the person who installs and configures LabKey Server, and can add others to the Site Administrators group. Any site admin can also add new users to the LabKey site and add those users to groups. Only a site admin can create a new project on LabKey or designate administrative privileges for a new project. The site admin has other unique privileges as well; see Site Administrator
for more information on the role of the site admin.
The Site Administrators group is implicit in all security settings. There's no option to grant or revoke folder permissions to this group under (Admin) > Folder > Permissions
The Developers group is a site-level security group that allows the creation of server-side scripts and code. Developers can add the following:
- <script> or <style> tags to HTML pages
- R reports to data grids (using the menu (Reports) > Create R Report on a data grid)
Note that Developers must also be assigned the Editor role in a given folder in order to add code in that folder.
Developers cannot add SQL queries using the schema browser.
Membership in the Developers group is managed on the page (Admin) > Site > Site Developers
To add users to the Developers group, add their emails to the text box Add New Members
, and click Update Group Membership
. Both sending notification emails and including a message with such a notification are optional.
To remove users from the Developers group, select them in the Remove
column, and click Update Group Membership
Note that you cannot impersonate the Developers group directly. As a workaroud, impersonate an individual user who has been added to the Developers group.
The Site Users Group
The site-level group consists of all users who are logged onto the LabKey system, but are not site admins. You don't need to do anything special to add users to the Site Users group; any users with accounts on your LabKey Server will be part of the Site Users group.
The Site Users group is global, meaning that this group automatically has configurable permissions on every resource on the LabKey site.
The purpose of the Site Users group is to provide a way to grant broad access to a specific resource within a project without having to open permissions for an entire project. Most LabKey users will work in one or a few projects on the site, but not in every project.
For instance, you might want to grant Reader permissions to the Site Users group for a specific subfolder containing public documents (procedures, office hours, emergency contacts) in a project otherwise only visible to a select team. The select team members are all still members of the site users group, meaning the resource will be visible to all users regardless of other permissions or roles.
The Guests/Anonymous Group
Anonymous users, or guests
, are any users who access your LabKey site without logging in. The Guests group is a global group whose permissions can be configured
for every project and folder. It may be that you want anonymous users to be able to view wiki pages and post questions to a message board, but not to be able to view MS2 data. Or you may want anonymous users to have no permissions whatsoever on your LabKey site. An important part of securing your LabKey site or project is to consider what privileges, if any, anonymous users should have.
Permissions for anonymous users can range from no permissions at all, to read permissions for viewing data, to write permissions for both viewing and contributing data. Anonymous users can never have administrative privileges on a project.