Step 2: Create the Assets via the Batch API

Here is a script that will create lots of Assets. Each one is self-explanatory, but there is a logic to the particular order, explained below the code.

# Create Scope, Workitems, Member, and assign the Workitems to the Member
AssetType: Scope
Parent: System (All Projects)
Name: SM Josh's Project
Schedule: Default Schedule
BeginDate: 3/20/2017
Workitems:
- AssetType: Epic
  Name: ES2015
  Subs:
  - AssetType: Story
    Name: Powered-up JavaScript
    Children:
    - AssetType: Task
      Name: Write and run tomorrow's code today
    - AssetType: Task
      Name: How Meteor already uses Babel
    - AssetType: Task
      Name: Babel already supports async / await
    - AssetType: Task
      Name: Painful asynchrony in today's JavaScript
    - AssetType: Test
      Name: "Code Challenge: Powered-up JavaScript"
  - AssetType: Story
    Name: ES5 and callback hell
    Children:
    - AssetType: Task
      Name: Asynchronous code and callback passing
    - AssetType: Task
      Name: Replace <code>function() {</code> with <code>() => {</code>
    - AssetType: Task
      Name: Curlyless arrow functions
    - AssetType: Task
      Name: Inline arrow functions
    - AssetType: Task
      Name: Can't get no...
    - AssetType: Test
      Name: "Code Challenge: ES5 and callback hell"
- AssetType: Epic
  Name: Operators
  Subs:
  - AssetType: Story
    Name: Operators 1
    Children:
    - AssetType: Task
      Name: Op 1 Step 1
    - AssetType: Task
      Name: Op 1 Step 2
    - AssetType: Task
      Name: Op 1 Step 3
    - AssetType: Task
      Name: Op 1 Step 4
    - AssetType: Test
      Name: "Code Challenge: Operators 1"
  - AssetType: Story
    Name: Operators 2
    Children:
    - AssetType: Task
      Name: Op 2 Step 1
    - AssetType: Task
      Name: Op 2 Step 2
    - AssetType: Task
      Name: Op 2 Step 3
    - AssetType: Task
      Name: Op 2 Step 4
    - AssetType: Task
      Name: Op 2 Step 5
    - AssetType: Test
      Name: "Code Challenge: Operators 2"
---
AssetType: Member
Name: SM Josh
Password: SM Josh
Nickname: SM Josh
Username: SM Josh
DefaultRole: Role.Name'Project Admin
Scopes: SM Josh's Project
---
AssetType: TeamRoom
Name: SM Josh's Room
Schedule: Default Schedule
Scope: SM Josh's Project
---
from: Story
where:
 Scope.Name: SM Josh's Project 
set:
 Owners: SM Josh
 Timebox: Iteration 1

Here's some analysis:

• We create the Scope, the new Project, first, and along with it, we create associated Epic, Story, Task, and Test Assets. The nesting allows the server to infer the correct relationships between Assets.
• After the Scope, we then create the new Member Asset, specifying everything we need to login and we can associate this new Member to the newly-created Scope with the name SM Josh's Project. The reason this works is because of Moniker support inside of the VersionOne Meta subsystem.
• Next, we create a TeamRoom, and rely on the Default Schedule.
• Finally, to make sure the new user owns the Story Assets we just made, we set the Owners attribute and also, to see them inside the new TeamRoom, the Timebox attribute.
• Note: We could have created our own Schedule and Timebox Assets from scratch, but it was easier for demonstration to keep it short and sweet.

You should see a response like this from the server, assuming you didn't specify the Prefer: respond-async header:

{
  "requestId": "c7dfee87-33b1-4521-8697-89513a876156",
  "createdDate": "2017-04-06T17:32:30.8253625Z",
  "completedDate": "2017-04-06T17:32:31.6694965Z",
  "duration": "00:00:00.8441340",
  "durationSeconds": 0.84413399999999994,
  "complete": true,
  "processing": false,
  "assetsCreated": {
    "oidTokens": [
      "Scope:11067",
      "Member:11096",
      "TeamRoom:11097"
    ],
    "count": 3
  },
  "assetsModified": {
    "oidTokens": [
      "Story:11069",
      "Story:11075",
      "Story:11083",
      "Story:11089"
    ],
    "count": 4
  },
  "assetsOperatedOn": {
    "oidTokens": [],
    "count": 0
  },
  "queryResult": {
    "results": [],
    "count": -1
  }
}