All Categories ​ > ​ ​For System Administrators ​ > ​ ​Managing the System ​ > ​   Managing Users (for System Admins)

Managing Users (for System Admins)

Updated by Vaida

The following information is only applicable to a Team or Enterprise instance of RSpace.

As Sysadmin or Community admin, you have several ways in which you can create, manage and interact with user accounts. You should login as a Sysadmin or Community Admin ONLY when you want to perform administrative tasks. If you act as both a user or PI in RSpace, AND you are ALSO a Sysadmin or Community admin, then you will need TWO separate accounts and should only log in with the appropriate account when you need to perform tasks related to those different roles. Note:

  • System Admin seats are not counted as part of your paid user seats.
  • We usually recommend that most servers have at least TWO system admins in case one of them is unavailable when they are needed for some urgent administrative task
  • We recommend that system admin account usernames be assigned to a specific person whose real name is included with the account details and that system admin accounts are not shared. This makes it easier to determine which system admin has performed which administrative tasks by searching the audit trail.
Do not add production data when logged in as a Sysadmin, or Community Admin, do not add Admins to any LabGroups, and do not ever try to use sysadmin account to fill the PI or standard user role.

Enabling/disabling user accounts

Users can be created, enabled or disabled by the RSpace system admin using the System > Users page. Your server can also be configured by Research Space to enable convenient "self-signup" (with or without user-by-user approval) so that users can create their own accounts when they visit the server for the first time. Talk to your trainer during your live Sysadmin training to decide which option is best for you.

The System > Users page displays your list of users and your current total of "Billable" (i.e. enabled) users and the number of remaining available seats on your license:

You can show or hide different columns on this page using the "COLUMNS" button and you cans also export the entire page with ALL columns as a .CSV file to conveniently study user metrics or build modified lists of users outside of RSpace.

When users are signed up and their account activated, their account is enabled. This is the standard user state and means that:

  • The user can login and view/edit their data.
  • The user appears in Group and Directory listings.
  • The user counts towards the license seat allocation.

Sometimes you might want to disable a user account, because someone has left your organization, or you want to adjust the available license seats, e.g. for rotation students.

To disable an account, search for the user in the System->Users page, then select the checkbox next to their name > click or tap "Actions" and choose "disable" in the dropdown. In the "Enabled" column, Enabled users are indicated with a green check, disabled users are shown with a red X. When the account is disabled, the user will not be able to log in. The user will also receive an email notifying them that their account is disabled. In some cases, Enabling and Disabling RSpace accounts can be linked to your SSO system using the RSpace API. Contact ResearchSpace support for details.

The consequences of a disabled account are :

  • User can no longer login.
  • User does not appear in directory or Group listings.
  • User cannot be invited to join a group.
  • User does not count towards license seat allocation.
  • Documents that the user has shared with others will continue to be readable or editable.
  • See also Long-term Data Management

To re-enable an account, search for the user in the System->Users page, then select the checkbox next to their name, and click the ‘Enable’ button that appears. Once re-enabled, their username will be displayed in green again, and their full account activity restored.

Some RSpace servers may be configured to allow the System Admin to see both a "Disable" and a "Delete User" button when a user is selected on the user management page. System Admins should NEVER delete any user account unless there is a compelling legal, data management or technical reason to do so. You can ask Research Space to hide the "Delete User" button on your server if you don't want to offer that option to your System Admin.

Operating as another user

Sometimes a user needs help or is experiencing a problem, and you might want to see the exact page that the user is seeing in order to investigate and help. This can be especially useful in the following situations:

You need to help a user change there password (on non-SSO servers).

You need to help a user change there email address or other profile information.

At the request of a PI, you need to change the sharing and data access setup for a user who has left your organization.

To perform these sorts of tasks, you can temporarily operate as that user, with exactly the same rights and permissions that they have.

Note that to use Operate As to work on a disabled user's inventory items, you may need to temporarily enable that user.

Steps

  1. Go to the System page
  1. Click on Operate As
  1. A popup panel will appear. Fill in the name of the user you wish to impersonate, and select them from the dropdown options that appear.
  1. You can choose whether the user will receive an email informing them that you are impersonating them – the default is that the system will do so, to give the user a polite notification. If you wish to operate without the user knowing, check the checkbox for Operate incognito.
  2. Fill in your own sysadmin password, then click on Submit.
  1. The page will redirect to the user’s home page and you will see a grey notice at the top reminding you that you’re using someone else’s account.
  1. When you’re done, click Release in the top bar, or just logout if you’ve finished your session.
Please be very careful about editing anything while operating as another user – although any changes will be attributed to you in the audit trail and revision history, it may cause concern to the user that you’re impersonating if they're not aware of it.

Contacting all users

You might wish to contact all users in the case of a system-wide announcement, eg. telling users to export their data if you are migrating from a test server. You can do so using Messaging, by clicking on Send a message in the Workspace toolbar:

Then, selecting "Message to all users" in the Request type. By default all message preferences are enabled, so a user who has not used the system will still get the message by email.

Unlocking a locked user account

If a user enters the wrong login credentials too many times, they get locked out for a short amount of time. However, a sysadmin can instantly unlock a user account if that is required, by going into the System tab, searching for the locked user (who will have a padlock next to their username), selecting the checkbox, then choosing "Unlock account" in the action menu.

Promoting a user to PI

Occasionally you will have a user with ‘User’ role who becomes a PI with their own lab group. You can promote this user within RSpace so that they have their own lab group. To do this:

Steps

  1. Go to System->Users page
  2. Search for, and select the user who you wish to promote
  3. Click on the ‘Promote to PI’ button.
  4. The user will now acquire a PI role, and have a LabGroup created for them. He can now invite his lab members to join the group.

The consequences of this action are:

  1. The new PI will be removed from existing lab groups, and any documents he had previously shared will be unshared.
  2. The  PI of his old  lab group (if he was in one) will no longer be able to see the new PI’s work.

Deleting a user

If your server has the deleteUser.enabled property enabled, then the system administrator will see a Delete button next to the usual "Disable" button and can use this to completely delete a user and all their work.

You should be absolutely sure there is nothing worth preserving before deleting a user – it is totally irreversible and physically deletes the user and all their work from the database. You can export and archive a copy of the user's data first if necessary

Typical use-cases might be:

  • There is a mistake or a typing error in the details of a recently created account (eg. wrong username)
  • You create a user account for the wrong person
  • You are required to delete all of a user's data for legal or privacy purposes

If a user you wish to delete has created some content, consider exporting their work in HTML and/or XML format, so that their data will be preserved.

Steps

  1. Navigate to System->Users page.
  2. Search for or browse to the user you want to delete.
  3. Select the checkbox by their name.
  4. Click "Actions" > delete and confirm by typing in the username.
  5. RSpace will confirm whether user removal was successful.

Currently, you can’t delete a user with Sysadmin or Community Admin role. Also, because of the irreversible nature of this deletion, you can only delete one user at a time.

If the ‘Delete User’ button does not appear, this is because the deleteUser.enabled property is set to false (the default). To enable this, edit your deployment.properties file on the server, so that:

deleteUser.enabled=true

and restart the server.

Deletion Safeguard

In version 1.51 we add an extra safeguard for backing up user data when a user is deleting. We do this by creating an XML zip of the user’s work that is generating when the user is deleted – this provides additional backup in case of accidental deletion, as most of a users work can be restored from the archive.

Transferring Forms

In the case where the user being deleted has published forms which have been used by other users, ownership of those forms will be transferred to the system administrator performing the deletion to maintain data integrity and ensure those published forms can continue to be used.

How did we do?

Powered by HelpDocs (opens in a new tab)