Skip to content

Commit 19f87c5

Browse files
patricijabreckoCopilot
patricijabrecko
and
Copilot
authored
Update docs (#14)
## Summary This pull request includes updates to the documentation for the Airdrop SDK, function invocation, and metadata extraction. ## Work item https://app.devrev.ai/devrev/works/ISS-190744 --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
1 parent 76f6306 commit 19f87c5

File tree

3 files changed

+97
-51
lines changed

3 files changed

+97
-51
lines changed

‎docs/airdrop_sdk_library_documentation.md‎

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -363,8 +363,9 @@ Defines the structure of events sent to external extractors from Airdrop platfor
363363
Required. An object containing:
364364

365365
- _secrets_: An object containing:
366-
- _service_account_token_: A **string** representing the DevRev authentication token for Airdrop platform
367-
- _snap_in_version_id_: A **string** representing the version ID of the snap-in
366+
- _service_account_token_: Required. A **string** representing the DevRev authentication token for Airdrop platform
367+
- _snap_in_version_id_: Required. A **string** representing the version ID of the snap-in
368+
- _snap_in_id_: Required. A **string** representing the snap-in ID.
368369

369370
- _payload_
370371

‎docs/function_invocation.mdx‎

Lines changed: 6 additions & 49 deletions
Original file line numberDiff line numberDiff line change
@@ -1,52 +1,9 @@
1-
A function can be invoked synchronously or asynchronously.
1+
The function is invoked by the runner.ts file.
2+
3+
runner.ts processes events of type "any", which are basically events of type "AirdropEvent" with some additional fields, and passes the events to the function. You can ignore the additional fields.
4+
25
You need to implement the run method in your function. The run method is called when the function is invoked. The run method signature is defined below:
36
```typescript
4-
type Context = {
5-
// ID of the dev org for which the function is being invoked.
6-
dev_oid: string;
7-
// ID of the automation/command/snap-kit Action/Event Source for which the function is being invoked.
8-
source_id: string;
9-
// ID of the snap-in as part of which the function is being invoked.
10-
snap_in_id: string;
11-
// ID of the snap-in Version as part of which the function is being invoked.
12-
snap_in_version_id: string;
13-
// ID of the service account.
14-
service_account_id: string;
15-
// This secrets map would contain some secrets which platform would provide to the snap-in.
16-
// `service_account_token`: This is the token of the service account which belongs to this snap-in. This can be used to make API calls to DevRev.
17-
// `actor_session_token`: For commands, and snap-kits, where the user is performing some action, this is the token of the user who is performing the action.
18-
secrets: Record<string, string>;
19-
};
20-
type ExecutionMetadata = {
21-
// A unique id for the function invocation. Can be used to filter logs for a particular invocation.
22-
request_id: string;
23-
// Function name as defined in the manifest being invoked.
24-
function_name: string;
25-
// Type of event that triggered the function invocation as defined in manifest.
26-
event_type: string;
27-
// DevRev endpoint to which the function can make API calls.
28-
// Example : "https://api.devrev.ai/"
29-
devrev_endpoint: string;
30-
};
31-
type InputData = {
32-
// Map of organization inputs and their corresponding values stored in snap-in.
33-
// The values are passed as string and typing needs to be handled by the function
34-
global_values: Record<string, string>;
35-
// Map of event sources and their corresponding ids stored in snap-in.
36-
// These could be used to schedule events on a schedule based event source.
37-
event_sources: Record<string, string>;
38-
};
39-
// Event sent to our app.
40-
type FunctionInput = {
41-
// Actual payload of the event.
42-
payload: Record<string, any>;
43-
// Context of the function invocation.
44-
context: Context;
45-
// Metadata of the function invocation.
46-
execution_metadata: ExecutionMetadata;
47-
input_data: InputData;
48-
};
49-
async function run(events: []FunctionInput): any;
7+
async function run(events: []AirdropEvent): void;
508
```
51-
As of now, it's safe to assume that only one event is passed to the function at a time. The function can be invoked multiple times for multiple events.
52-
The value returned from the `run` method is passed back in synchronous execution modes, such as commands, snap kit actions, and event source synchronous execution. In asynchronous execution modes, such as automation execution, the return value is ignored.
9+
As of now, it's safe to assume that only one event is passed to the function at a time. The function can be invoked multiple times for multiple events.

‎docs/metadata-extraction.mdx‎

Lines changed: 88 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,88 @@
1+
### Configure state transitions
2+
3+
If an external record type has some concept of states, between which only certain transitions are
4+
possible (for example, to move to the `resolved` status, an issue first has to be `in_testing`), you
5+
can declare these in the metadata too.
6+
7+
This allows creation of a matching *stage diagram* (a collection of stages and their permitted
8+
transitions) in DevRev, which enables a much simpler import and a closer preservation of the external
9+
data than mapping to DevRev's built-in stages.
10+
11+
To declare this in the metadata, make sure the status is represented as an enum field, and then
12+
declare the allowed transitions (which you might have to retrieve from an API at runtime, if they
13+
are also customized):
14+
15+
```json
16+
{
17+
"fields": {
18+
"status": {
19+
"name": "Status",
20+
"is_required": true,
21+
"type": "enum",
22+
"enum": {
23+
"values": [
24+
{
25+
"key": "detected",
26+
"name": "Detected"
27+
},
28+
{
29+
"key": "mitigated",
30+
"name": "Mitigated"
31+
},
32+
{
33+
"key": "rca_ready",
34+
"name": "RCA Ready"
35+
},
36+
{
37+
"key": "archived",
38+
"name": "Archived"
39+
}
40+
]
41+
}
42+
}
43+
},
44+
"stage_diagram": {
45+
"controlling_field": "status",
46+
"starting_stage": "detected",
47+
"all_transitions_allowed": false,
48+
"stages": {
49+
"detected": {
50+
"transitions_to": ["mitigated", "archived", "rca_ready"],
51+
"state": "new"
52+
},
53+
"mitigated": {
54+
"transitions_to": ["archived", "detected"],
55+
"state": "work_in_progress"
56+
},
57+
"rca_ready": {
58+
"transitions_to": ["archived"],
59+
"state": "work_in_progress"
60+
},
61+
"archived": {
62+
"transitions_to": [],
63+
"state": "completed"
64+
}
65+
},
66+
"states": {
67+
"new": {
68+
"name": "New"
69+
},
70+
"work_in_progress": {
71+
"name": "Work in Progress"
72+
},
73+
"completed": {
74+
"name": "Completed",
75+
"is_end_state": true
76+
}
77+
}
78+
}
79+
}
80+
```
81+
82+
In the above example:
83+
- The status field is the controlling field of the stage diagram.
84+
- If a status field has no explicit transitions but you still want a stage diagram, set `all_transitions_allowed` to `true`, which creates a diagram where all the defined stages can transition to each other.
85+
- External systems may categorize statuses (like Jira's status categories), which can be included in the diagram metadata (`states` in the example).
86+
- The `starting_stage` defines the initial stage for new object instances. This data should always be provided if available, otherwise the starting stage is selected alphabetically.
87+
- The order and human-readable name are taken from the enum values defined on the controlling field.
88+
- If the `states` field is not provided, default DevRev states are used: `open`, `in_progress`, and `closed`.

0 commit comments

Comments
 (0)