All Categories ​ > ​ ​For PIs ​ > ​ ​Data Management ​ > ​   Long-term Data Management

Long-term Data Management

Updated by Vaida

It is understandable that PIs want to have continued access to, or ownership of, work produced in their lab. Researchers and team members may come and go over time. In science, it's important to build upon past work so scientists often need to access legacy data, or reproduce the results of experiments performed by people who may no longer be part of your lab. RSpace is designed specifically for this purpose.

A list of LabGroup members is displayed in the LabGroup management page for your LabGroup. When someone leaves your organization, their account is usually disabled by your RSpace System Admin. Disabled users are automatically moved to a new section in the PI's view of the LabGroup page called "Disabled Users". Disabled users can no longer log in, but their data can be permanently accessed exactly as before, as long as they are not removed from the LabGroup.

In many cases, since it is easy to see the data of former lab members by default, when a LabGroup member leaves, and their account is disabled, no further action may be necessary. However, be sure to consider some of the options and best practices described below.

If you are using RSpace Community Edition, then you do not have access to your own RSpace System Admin account. You will need to ask the departing users to send a request to Research Space to disable their accounts.
Note that if you are using RSpace Community Edition, the data of disabled users may be deleted after 12 months of inactivity, so if you are a PI, you might want to EXPORT the data of disabled users for permanent storage outside of RSpace, or reimport back into some other active user account.
If you are using RSpace Team or Enterprise Edition, Disabled users do not count toward your billable total of licences, and there is no fee for maintaining the data created by disabled users (i.e. former LabGroup members) on your Rspace server forever.
If you are using RSpace Enterprise Edition and RSpace is integrated with your institutional SSO system, then it is still a best practice for the RSpace admin to manually disable the accounts of users who have left your organization. However note that even if the account is not disabled, former users will lose access to your SSO authenticated RSpace server once your IT team deactivates their SSO account. In some cases, the RSpace API can be used to make sure that when an SSO account is disabled, the corresponding RSpace account is also automatically disabled.

The example below shows a LabGroup with a single Disabled Account. Over the years, it is likely that the number of disabled users will grow. Eventually there may be many fromer LabGroup members listed, perhaps more even than your list of "current" LabGroup members. Note that in this image you can also see that the PI has access to an "Export Work" button for each user that they can use to easily get a copy of all work by that user.

If you are a PI and you notice that a user who has left your organization has NOT been moved to the "Disabled Accounts" section, you should contact the RSpace system admin and remind them that the account needs to be disabled. Your organization pays for all enabled accounts, plus enabled accounts consume a seat license thay could be used for some other user at your organization.

If necessary a user can be removed from the group list by clicking the Remove button. Depending on your LabGroup organizational structure, the user's former PI may no longer have access to that work once a user is removed from their LabGroup, however, the user's work continues to be stored on the system for as long as it exists, and remains accessible to the sysadmin and perhaps other colleagues if, for example, they have moved to a new LabGroup. The sysdmin can add the former user BACK to the old LabGroup if necessary (e.g., if a PI clicks "Remove" by mistake), or the System Admin can choose to add the disabled user to any other Group to grant access to the former user's data.

Alternatively, a copy of ALL the user's work, or perhaps just some parts of it (e.g., important work located in a specific shared folder or subfolder) can be exported and imported back to the account of some other user. See "Transfer using Export - Import section below".

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 System tab > Users page. System Admins should not delete user accounts unless there is a compelling legal, data management or technical reason to do so. You can ask ResearchSpace to hide the "Delete User" button on your server if you don't want to offer that option to your sysdmin.

Reorganizing data of former users

It's a good best practice for PIs to meet with departing users to review the following:

• Sharing and permissions settings for all work belonging to the departing user so that future access is optimized. If necessary, PIs can ask their RSpace sysdmin to assist with adjusting the sharing schema and/or access permissions for former users who are no longer available. The System Admin can also do this on behalf of a user using the System tab > Operate As feature.

• Reorganization of the work if necessary. One common scenario for "reorganization" via moving and selective sharing is to adjust the access of legacy work located in shared notebooks owned by a former user such that the same work will also appear in a newer notebook owned by someone else who has taken over that project. Another strategy might be to unshare ALL work by a departing user, and then use autoshare to reshare it to a single named folder named after the user who has left, so that all of that user's work is available with read-only access in a single location. You can find more information about various data sharing and management scenarios here. If you forget to ask a user to reorganize work when they leave, you can ask the sysdmin to do it using the System tab > Operate As feature.

• Export options for the departing user. The user can visit the My RSpace Export-Import page and use "Export all my work" to get a copy in an appropriate format (s) to take with them or to leave with the PI as appropriate.

Transfer using Export - Import

Users (or their PI, or the sysadmin) can also EXPORT a copy of some or all of a user's data as XML and then reimport it to a different account, (or even a different server). The data can be physically downloaded by the user or downloaded by a PI or sysadmin and physically provided to the user, or the PI or sysadmin can get the download link for the data from their notification area and send the link to the user. This method may not always be ideal for migration from one account to another on the same server though, because it generates a new duplicate copy of the data. Generally a good best practice in RSpace is to avoid creating multiple copies of work in the system whenever possible so that you don't later have to deal with ambiguous duplicate results when you use the RSpace search tool to relocate the work, although sometimes this may be unavoidable.

How did we do?

Powered by HelpDocs (opens in a new tab)