Organization Team

The Organization team page is only visible to users who are organization superusers for that organization. It lists all users in the organization and information about each user:

  • Is the user active (i.e. can they log in). If the user account is inactive, the last project invitation which has not been accepted (if any) will be displayed with a link to the Project Team page.

  • Is the user an Organization Superuser

  • Can the user access the User API

  • Can the user manage Medidata Rave URLs settings for Automated Testing

  • Can the user view Organization Reports

  • Can the user create and manage their own personal API tokens (see Managing API tokens)

  • What authentication method is the user using (Internal or Single Sign On (SSO) if available) and does the user have two-factor authentication active

  • How many failed login attempts have their been on this users account since the last successful login

  • When was the users last successful login

Updating Organization-level user permissions

Users with Organization Superuser permission can edit these settings for themselves and for other users from the list.

Note that the option to change the users authentication method is only shown if the Organization is set to use Single Sign On (SSO). In that case it is possible to set the user to use the SSO method or to opt out of it and use username/password and two factor authentication provided by TrialGrid.

Unique employee id value may be edited. If present this should be unique within the organization.

Allowing users to manage API tokens

The Can create and manage personal API tokens permission controls whether a user can create, view, and revoke their own API tokens from their user profile, and whether they can obtain a token via the api/v<n>/api-token-auth/ endpoint. Users without this permission see no API Tokens tab on their profile and receive 403 Forbidden from the endpoint.

Tokens are stored as one-way hashes; the token value is shown to the user once at the time of creation and cannot be recovered afterwards. Disabling this permission for a user prevents new tokens being created and also blocks any existing tokens from authenticating — re-enabling the permission restores access for the user's existing (non-revoked) tokens. To permanently destroy a user's tokens, an Organization Superuser should ensure the user revokes them (or the user can do so themselves before the permission is removed) and the user account is then deactivated.

Users who already held an API token at the time this permission was introduced have it enabled automatically so that existing integrations are not broken. New users have it disabled by default.

For details of the user-facing flow and the API endpoints, see Token Authentication.