Long-term Data Management

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, and in science, it's often important to build upon past work, 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 accessed exactly as before, as long as they are not removed from the LabGroup.

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.
If you are using RSpace 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 an SSO authenticated RSpace server once your IT team deactivates their SSO account.

The example below shows 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.

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, and remains accessible to the sysadmin and perhaps other colleagues if, for example, they have moved to a new LabGroup. The System Admin 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 user to any other LabGroup.

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 as XML and imported back to the account of some other user in the old LabGroup using My RSpace > Export-Import tab.

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 System Admin.

Reorganizing data of former users

It's a good best practice to ask departing users who are leaving your organization or LabGroup to review their shared data and adjust permissions to facilitate future access. If necessary, PIs can ask their RSpace System Admin to assist with adjusting the sharing schema and/or access permissions for former users who are no longer available. The System Admin can do this using the System tab > Operate As feature.

One common scenario for "reorganization" via selective sharing is to adjust the access of legacy work that exists in a shared notebook 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 fine more information about various data sharing and management scenarios here.

Transfer using Export - Import

Users (or their PI, or the sysadmin) can also EXPORT a copy of user's data as XML and then reimport it to a different account, (or even a different server). This method may not be ideal though, because it generates a new 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)

Powered by HelpDocs (opens in a new tab)