Organization Team

The Organization team page is only visible to users whose Organization Role has the "Administer Permissions" permission. 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.

  • Which Organization Role the user holds. The role decides what they may do here: whether they can administer permissions, access the User API, manage Medidata Rave URLs settings for Automated Testing, view Organization Reports, manage Import Scripts, and create 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

Giving a user Organization permissions

What a user may do in the Organization is decided by their Organization Role. Open the user from the list and choose a role from the Organization Role list. Choose "No role" to give them no Organization permissions at all.

Roles are defined on the Organization Roles page. If nobody has the combination of permissions you want yet, create the role there first, then come back and choose it.

Changing a role changes what every user holding it can do, straight away. If you want to change one person only, put them on a different role.

Users with the "Administer Permissions" permission can do this for themselves and for other users.

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 Icons

The Can manage Icons permission, granted through a role, controls whether a user can add and change the Organization's Icons. Everyone in the Organization can see the icon list without it.

Being able to administer permissions does not give a user this permission. Someone who administers permissions and also needs to manage icons puts themselves on a role that has both.

Users who could manage icons before this permission existed keep that ability. The permission was set for them automatically.

Allowing users to manage API tokens

The Can create and manage personal API tokens permission, granted through a role, 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, someone who can administer permissions 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.

Allowing users to manage Import Scripts

The Can manage Import Scripts permission, granted through a role, controls whether a user can create, change and delete Import Scripts for the Organization. Being able to administer permissions does not give a user this permission. Someone who administers permissions and also needs to manage Import Scripts puts themselves on a role that has both.

It does not control who can see a script. Everyone in the Organization can open the Import Scripts page and read any script, including its code. The permission decides who can change one.

Give it only to people you trust to write these scripts. A script is written once for the Organization and is then run by other people, using their own access rather than the author's.