As described in Getting Started / Configuration, the -d data flag is a required parameter to specify a newline-separated text file indicating what projects to import. For convenience, a file called allData.txt is included which will pull all previously prepared sample data. For any project, the script expects two things: a YAML configuration file to define the structure of the project and a folder containing the data for the project. The YAML file must be titled "$projectId_metadata.yaml". The data folder should contain individually zipped sessions at the top level. When the script starts, it will read the text file and begin checking for these files. If the ./data folder does not already contain the YAML file, the script will search for it on the NRG FTP site. Likewise, if the ./data folder does not contain the folder containing the data for the project (or its zip), the script will attempt to locate a zip by the project ID on the NRG FTP site. Below is an example project YAML file which contains most of the currently supported operations (note that the file would necessarily be called study_001_metadata.yaml):
Tips on the YAML above:
The anonymization section mirrors the syntax exactly of how it is used in Site Configuration, except now it is added to the project.
sessions versus complexSessions
The sessions element allows you to easily define an array of sessions which will all be uploaded to the XNAT server as is. So, while it is exceedingly easy to specify the sessions as an array like this, you lose power to fine-tune the sessions, as needed. So, if you want to do this, you specify the sessions under complexSessions, instead. The sessions here will also be uploaded through the session importer, but additional modifications will be added. So, the study_001 folder for this project should contain the following files:
The format for sharing differs depending on whether the object being shared is a subject or session. For a subject, the child elements of share are one or more destination projects. Each of these destination projects takes zero or more key-value pairs to customize the sharing. In the above example, subject Subj_004 is being shared into a single project, "DEST_PROJ" while being given the label "DEST_SUBJ_LABEL". In addition to specifying the label, also supported is passing shareAllSessions : true, which will share all of the sessions from this subject into the destination project with labels as is (included for convenience). The sharing for a session is easier. The child elements of share on a complexSession element are one or more key-value pairs of destination project to destination label of the session. So, in the above example, session 0000004 would be shared to project DEST_PROJ with the session label DEST_LABEL
If the users already exist, and the XNAT user running the script has access to the site user list, the users will be added to the project in their corresponding roles. If the users do not already exist, insecure users will be created (the password is just the username), which should not be used in production (this requires admin access).