Auto generated docs from tests

AssignMemberWithRoleJson.md

Execute AssignMemberWithRole Operation upon a Scope for list of Members by OID Token

Demonstrates how to use a single command to assign multiple Members to a Scope along with Scope-specific roles each Member will have for the target Scope.

Setup

For the context of this example, the following request will setup the instance with the needed starting conditions:

POST http://host/instance/api/asset

[
        {
                "from": "Member",
                "filter": [
                        "Name='scopeListMember1','scopeListMember2'"
                ],
                "execute": "Delete"
        },
        {
                "AssetType": "Scope",
                "Name": "Project for List of Members",
                "Parent": "Scope:0",
                "BeginDate": "2019-11-01T17:39:16.040Z"
        },
        {
                "AssetType": "Member",
                "Name": "scopeListMember1",
                "Password": "scopeListMember1",
                "Nickname": "scopeListMember1",
                "Username": "scopeListMember1",
                "DefaultRole": "Role.Name'Observer"
        },
        {
                "AssetType": "Member",
                "Name": "scopeListMember2",
                "Password": "scopeListMember2",
                "Nickname": "scopeListMember2",
                "Username": "scopeListMember2",
                "DefaultRole": "Role.Name'Observer"
        }
]

Request

The following request invokes the behavior:

POST http://host/instance/api/asset

{
        "from": "Scope:1096",
        "execute": {
                "op": "AssignMemberWithRole",
                "list": [
                        {
                                "Member": "Member:1097",
                                "Role": "Role:3",
                                "IsOwner": true
                        },
                        {
                                "Member": "Member:1098",
                                "Role": "Role:7",
                                "IsOwner": false
                        }
                ]
        }
}

Response

Expect a result similar to this:

{
        "requestId": "6818598f-afc4-419b-9829-2be58cf56557",
        "createdDate": "2019-11-01T17:39:16.2306754Z",
        "completedDate": "2019-11-01T17:39:16.2486756Z",
        "duration": "00:00:00.0180002",
        "durationSeconds": 0.018000199999999997,
        "complete": true,
        "processing": false,
        "assetsCreated": {
                "oidTokens": [],
                "count": 0
        },
        "assetsModified": {
                "oidTokens": [],
                "count": 0
        },
        "assetsOperatedOn": {
                "oidTokens": [
                        "Scope:1096",
                        "Scope:1096"
                ],
                "count": 2
        },
        "commandFailures": {
                "commands": [],
                "count": 0
        },
        "queryResult": {
                "results": [],
                "count": -1
        }
}

AssignMemberWithRoleYaml.md

Execute AssignMemberWithRole Operation upon a Scope for list of Members by OID Token

Demonstrates how to use a single command to assign multiple Members to a Scope along with Scope-specific roles each Member will have for the target Scope.

Setup

For the context of this example, the following request will setup the instance with the needed starting conditions:

POST http://host/instance/api/asset

from: Member
filter:
- Name='scopeListMember1','scopeListMember2'
execute: Delete
---
AssetType: Scope
Name: Project for List of Members
Parent: Scope:0
BeginDate: 2019-11-01T17:39:10.306Z
---
AssetType: Member
Name: scopeListMember1
Password: scopeListMember1
Nickname: scopeListMember1
Username: scopeListMember1
DefaultRole: Role.Name'Observer
---
AssetType: Member
Name: scopeListMember2
Password: scopeListMember2
Nickname: scopeListMember2
Username: scopeListMember2
DefaultRole: Role.Name'Observer

Request

The following request invokes the behavior:

POST http://host/instance/api/asset

from: Scope:1093
execute:
 op: AssignMemberWithRole
 list:
 - Member: Member:1094
   Role: Role:3
   IsOwner: true
 - Member: Member:1095
   Role: Role:7
   IsOwner: false

Response

Expect a result similar to this:

{
        "requestId": "bfa5ca20-4496-42bf-85cb-bef171c7f14f",
        "createdDate": "2019-11-01T17:39:15.8936899Z",
        "completedDate": "2019-11-01T17:39:15.9372191Z",
        "duration": "00:00:00.0435292",
        "durationSeconds": 0.0435292,
        "complete": true,
        "processing": false,
        "assetsCreated": {
                "oidTokens": [],
                "count": 0
        },
        "assetsModified": {
                "oidTokens": [],
                "count": 0
        },
        "assetsOperatedOn": {
                "oidTokens": [
                        "Scope:1093",
                        "Scope:1093"
                ],
                "count": 2
        },
        "commandFailures": {
                "commands": [],
                "count": 0
        },
        "queryResult": {
                "results": [],
                "count": -1
        }
}

error_cascade.md

Error: Create Epic and Subs where Scope is invalid causes cascade of four failures

Demonstrates how the API will return a cascade of failures when an invalid Scope is specified for a top-level Epic that has a collection of Subs. The failure messages can be modified and resubmitted to the API to create the original request's Assets.

HTTP Request

The following request invokes the behavior:

POST http://V1Host/V1Instance/api/asset

Payload:

{
	"AssetType": "Epic",
	"Scope": "Scope:9999",
	"Name": "My Epic on a Scope that DOES NOT EXIST which will produce a cascade of four failures!",
	"Subs": [
		{
			"AssetType": "Story",
			"Name": "My Story",
			"Children": [
				{
					"AssetType": "Test",
					"Name": "My Test"
				},
				{
					"AssetType": "Task",
					"Name": "My Task"
				}
			]
		}
	]
}

HTTP Response

Expect a result similar to this:

{
	"requestId": "6a1ffaf0-79cb-4486-be67-4c71949f88aa",
	"createdDate": "2019-11-05T20:31:42.5455557Z",
	"completedDate": "2019-11-05T20:31:42.5545265Z",
	"duration": "00:00:00.0089708",
	"durationSeconds": 0.0089708,
	"complete": true,
	"processing": false,
	"assetsCreated": {
		"oidTokens": [],
		"count": 0
	},
	"assetsModified": {
		"oidTokens": [],
		"count": 0
	},
	"assetsOperatedOn": {
		"oidTokens": [],
		"count": 0
	},
	"commandFailures": {
		"commands": [
			{
				"@468b13d1-cacb-496f-b3bc-82fd25e4c632": {
					"AssetType": "Epic",
					"Scope": "Scope:9999",
					"Name": "My Epic on a Scope that DOES NOT EXIST which will produce a cascade of four failures!"
				},
				"error": {
					"message": "Violation'Invalid'Epic.Scope",
					"sourceCommandIndex": 0
				}
			},
			{
				"@c38efe0d-3052-488a-bb7c-b6d0cc50c286": {
					"AssetType": "Story",
					"Name": "My Story",
					"#ContextOid": "@468b13d1-cacb-496f-b3bc-82fd25e4c632"
				},
				"error": {
					"message": "Invalid OID token: @468b13d1-cacb-496f-b3bc-82fd25e4c632",
					"sourceCommandIndex": 0
				}
			},
			{
				"@1c9bc6da-7ab1-4251-bf25-2a8d23b4e217": {
					"AssetType": "Test",
					"Name": "My Test",
					"#ContextOid": "@c38efe0d-3052-488a-bb7c-b6d0cc50c286"
				},
				"error": {
					"message": "Invalid OID token: @c38efe0d-3052-488a-bb7c-b6d0cc50c286",
					"sourceCommandIndex": 0
				}
			},
			{
				"@1909a37f-3c2e-40cc-aead-05ac4d5bfe7d": {
					"AssetType": "Task",
					"Name": "My Task",
					"#ContextOid": "@c38efe0d-3052-488a-bb7c-b6d0cc50c286"
				},
				"error": {
					"message": "Invalid OID token: @c38efe0d-3052-488a-bb7c-b6d0cc50c286",
					"sourceCommandIndex": 0
				}
			}
		],
		"count": 4
	},
	"queryResult": {
		"results": [],
		"count": -1
	}
}

• Notice that objects returned in the commandFailures property are in the form of complete commands. In this particular example, you would be able to edit the Scope value to point to an actual scope and resubmit either the original payload that had the nested assets, or simply submit the array of four commands in the failture details. Since the descendant nodes have been auto-aliased by the server, they will get processed properly by reference when resubmitted.
• Also notice that each failure has a sourceCommandIndex property that identifies a zero-based index of the command that generated this error from your original payload. Because our original payload contained nested assets, each of these commands has 0 for this value.