You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each table the tap imports is implemented as a `Stream`. If you want to export a new table then you can just add a new `stream_<tablename>` and implement the stream interface. See the tap folder for more examples.
25
+
26
+
## Adding new fields and schemas
27
+
28
+
The translation / interface layer between incident.io types and singer types are all contained within the `model` folder. To implement a new type or schema add a new file and implement the following methods:
29
+
30
+
-`Schema()` - singer schema representing the full type, may have `Optional()` and `ArrayOf` types
31
+
-`Serialize()` - takes the incident.io client type and returns data in the format specified by the `Schema()` method
@@ -41,3 +41,155 @@ You can check this works by running:
41
41
```console
42
42
$ tap-incident --discover --config=config.json
43
43
```
44
+
45
+
## Configuring exports
46
+
47
+
By default the tap will export all data it can.
48
+
49
+
If you want to control what fields and tables you wish to export you will need a catalog file. You can use the discover command to create a default catalog file which will contain all streams and columns along with their properties.
The catalog file follows the Singer specification to enable or disable a stream add the field `selected: <true|false>` inside the streams top level metadata. For example to disable exporting severities:
56
+
57
+
```json
58
+
{
59
+
"streams": [
60
+
{
61
+
"stream": "severities",
62
+
"tap_stream_id": "severities",
63
+
"schema": {
64
+
...
65
+
},
66
+
"metadata": [
67
+
{
68
+
"breadcrumb": [],
69
+
"metadata": {
70
+
"selected": false, // Add this
71
+
"inclusion": "available",
72
+
"selected-by-default": true,
73
+
"forced-replication-method": "FULL_TABLE"
74
+
}
75
+
},
76
+
{
77
+
"breadcrumb": [
78
+
"properties",
79
+
"id"
80
+
],
81
+
```
82
+
83
+
You can adjust which columns within a stream you wish to export similarly, by adding the same field inside the metadata for that column, for example to not export a description field:
84
+
85
+
```json
86
+
{
87
+
"breadcrumb": [
88
+
"properties",
89
+
"description"
90
+
],
91
+
"metadata": {
92
+
"inclusion": "available",
93
+
"selected": false, // Add this
94
+
"selected-by-default": true
95
+
}
96
+
},
97
+
```
98
+
99
+
## Table Information
100
+
101
+
### Incidents
102
+
103
+
- Table name: incidents
104
+
- Description: Incidents are a core resource, on which many other resources (actions, etc) are created. You will find incident specific actions, updates, timestamps etc nested on this resource.
105
+
- Primary key column(s): id
106
+
- Replication: full table
107
+
- API documentation: [Incidents V2](https://api-docs.incident.io/tag/Incidents-V2)
108
+
109
+
### Actions
110
+
111
+
- Table name: actions
112
+
- Description: Incident actions are used during an incident, to track work such as 'restart the database' or 'contact the customer'. Actions are also included in the incidents table.
113
+
- Primary key column(s): id, incident_id
114
+
- Replication: full table
115
+
- API documentation: [Actions V2](https://api-docs.incident.io/tag/Actions-V2)
116
+
117
+
### Custom Field Options
118
+
119
+
- Table name: custom_field_options
120
+
- Description:
121
+
- Primary key column(s): id, custom_field_id
122
+
- Replication: full table
123
+
- API documentation: [Custom Field Options V1](https://api-docs.incident.io/tag/Custom-Field-Options-V1)
124
+
125
+
### Custom Fields
126
+
127
+
- Table name: custom_fields
128
+
- Description: Custom fields are used to attach metadata to incidents, which you can use when searching for incidents in the dashboard, triggering workflows, building announcement rules or for your own data needs.
129
+
- Primary key column(s): id
130
+
- Replication: full table
131
+
- API documentation: [Custom Fields V2](https://api-docs.incident.io/tag/Custom-Fields-V2)
132
+
133
+
### Follow Ups
134
+
135
+
- Table name: follow_ups
136
+
- Description: Incidents can have follow-ups associated with them, which track work that should be done after an incident (e.g. improving some documentation, or upgrading a dependency). They can also be exported to external issue trackers.
137
+
- Primary key column(s): id, incident_id
138
+
- Replication: full table
139
+
- API documentation: [Follow Ups V2](https://api-docs.incident.io/tag/Follow-ups-V2)
140
+
141
+
### Incident Roles
142
+
143
+
- Table name: incident_roles
144
+
- Description: During an incident, you can assign responders to one of the incident roles that are configured in your organisation settings.
145
+
- Primary key column(s): id
146
+
- Replication: full table
147
+
- API documentation: [Incident Roles V2](https://api-docs.incident.io/tag/Incident-Roles-V2)
148
+
149
+
### Incident Statuses
150
+
151
+
- Table name: incident_statuses
152
+
- Description: Each incident has a status, picked from one of the statuses configured in your organisations settings.
153
+
- Primary key column(s): id
154
+
- Replication: full table
155
+
- API documentation: [Incident Statuses V1](https://api-docs.incident.io/tag/Incident-Statuses-V1)
156
+
157
+
### Incident Timestamps
158
+
159
+
- Table name: incident_timestamps
160
+
- Description: Each incident has a number of timestamps; some being defaults that we set on each incident for you, and other being configured for your organisation within settings.
161
+
- Primary key column(s): id
162
+
- Replication: full table
163
+
- API documentation: [Incident Timestamps V2](https://api-docs.incident.io/tag/Incident-Timestamps-V2)
164
+
165
+
### Incident Types
166
+
167
+
- Table name: incident_types
168
+
- Description: With incident types enabled, you can tailor your process to the situation you're responding to with different custom fields and roles for each incident type.
169
+
- Primary key column(s): id
170
+
- Replication: full table
171
+
- API documentation: [Incident Types V1](https://api-docs.incident.io/tag/Incident-Types-V1)
172
+
173
+
### Incident Updates
174
+
175
+
- Table name: incident_updates
176
+
- Description: Incident Updates allows you to see all the updates that have been shared against a particular incident. This will include any time that the Severity or Status of an incident changed, alongside any additional updates that were provided. Incident updates are also included in the Incidents table
177
+
- Primary key column(s): id, incident_id
178
+
- Replication: full table
179
+
- API documentation: [Incident Updates V2](https://api-docs.incident.io/tag/Incident-Updates-V2)
180
+
181
+
### Severities
182
+
183
+
- Table name: severities
184
+
- Description: Each incident has a severity, picked from one of the severities configured in your organisations settings.
185
+
- Primary key column(s): id
186
+
- Replication: full table
187
+
- API documentation: [Severities V1](https://api-docs.incident.io/tag/Severities-V1)
188
+
189
+
### Users
190
+
191
+
- Table name: users
192
+
- Description: Users all have a single base role, and can be assigned multiple custom roles. They can be managed via your Slack workspace or SAML provider.
193
+
- Primary key column(s): id, custom_field_id
194
+
- Replication: full table
195
+
- API documentation: [Users V2](https://api-docs.incident.io/tag/Users-V2)
0 commit comments