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
docs: add filtering documentation and enhance Object Customization guide (#236)
- Explain DevRev object and leaf_type.
- Add a section on filtering.
- Remove the beta warning at the top.
The process to make the APIs public is in progress, and we'll anyways
not break the beta APIs.
- Fix headers. The Accept header is redundant, and Content-Type is mandatory.
- Remove redundant uses of "Let's say..." while maintaining the educational tone.
Copy file name to clipboardExpand all lines: fern/docs/pages/customization.mdx
+77-41Lines changed: 77 additions & 41 deletions
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,27 @@
1
-
<Calloutintent="warning">
2
-
This functionality is in Beta. It is not recommended for use in production applications.
3
-
</Callout>
4
-
5
1
DevRev allows you to customize its core objects such as _issue_ and _ticket_ to fit
6
2
your organization's unique workflows and reporting needs. By using the customization
7
3
framework, you can extend these objects with custom fields that reflect your processes.
8
4
9
-
This guide provides an overview of the customization framework and walks you through the process of tracking bugs in your organization. By the end of this guide, you'll be able to:
10
-
1. Customize DevRev objects such as _issue_ and _ticket_.
5
+
This section provides an overview of the customization framework and walks you through the
6
+
process of tracking bugs in your organization. By the end of this section, you'll be able
7
+
to:
8
+
1. Customize DevRev objects such as _issue_ and _ticket_ by adding custom fields.
9
+
1. Override default field settings of DevRev objects.
11
10
1. Create custom stages and stage transition diagrams for your objects.
12
11
1. Create dependent fields for your objects.
13
12
14
13
## Concepts
15
14
15
+
### DevRev object
16
+
17
+
DevRev objects are the core entities that represent real-world items such as issues,
18
+
tickets, and incidents. Each object type has a set of fields that describe the object.
19
+
20
+
<Calloutintent="tip">
21
+
When you encounter `leaf_type` in the documentation or API, it refers to the type of DevRev
22
+
object you're working with, such as an _issue_ or _ticket_.
23
+
</Callout>
24
+
16
25
### Schema fragment
17
26
18
27
DevRev objects are customized using _schema fragments_. A fragment is a building block
@@ -40,7 +49,10 @@ Subtypes are defined using a schema fragment of type `custom_type_fragment`.
40
49
41
50
## Customizing a DevRev object
42
51
<Calloutintent="note">
43
-
Let's say you want to track bugs across various environments in your organization.
52
+
Your team needs to track software bugs. You want to know:
53
+
- Which environments are affected (development, testing, production)
54
+
- Whether it's a regression (a bug in previously working code)
55
+
- The root cause analysis (RCA) of the bug
44
56
</Callout>
45
57
46
58
First, create a schema fragment defining the fields for the _bug_ subtype.
@@ -49,7 +61,6 @@ Make sure to replace `<TOKEN>` with your API token.
@@ -195,7 +202,9 @@ The following observations can be made from the above example:
195
202
- Subtype fields are of the form `ctype__<field_name>`.
196
203
- Tenant fields are of the form `tnt__<field_name>`.
197
204
* References to each fragment are stored with the object.
198
-
* When updating an object, the `custom_schema_spec` can specify only the fragments being modified. Here, only the tenant fragment is specified as only the release notes field is being updated.
205
+
* When updating an object, the `custom_schema_spec` can specify only the fragments being
206
+
modified. Here, only the tenant fragment is specified as only the release notes field
207
+
is being updated.
199
208
200
209
## Supported custom field types
201
210
@@ -214,8 +223,37 @@ The following custom field types are supported -
214
223
| date |`"2020-10-20"` (YYYY-MM-DD) |
215
224
| id |`"don:core:dvrv-us-1:devo/test:issue/1"`|
216
225
217
-
The list variants of all the supported custom field types are also supported. For
218
-
example, `[]int`, `[]tokens`, etc.
226
+
The list variants of all the supported custom field types are also supported.
227
+
In the example above, the `impacted_environments` field is a list of enum values.
228
+
229
+
## Filtering DevRev objects
230
+
231
+
<Calloutintent="note">
232
+
To demonstrate filtering capabilities, consider finding all bugs in the production
233
+
environment that had a customer impact.
234
+
</Callout>
235
+
236
+
This translates to filtering _issue_ objects with subtype _bug_, _customer_impact_ set
237
+
to `true` and _impacted_environments_ containing `"Prod"`.
* The API payload reflects the entire state of the new fragment version.
279
-
* The `deleted_fields` array specifies the field names that are being deleted. If not provided, the API call fails due to the lack of an explicit field deletion confirmation. This prevents accidental field deletions.
317
+
* The `deleted_fields` array specifies the field names that are being deleted. If not
318
+
provided, the API call fails due to the lack of an explicit field deletion
319
+
confirmation. This prevents accidental field deletions.
280
320
281
321
The above API call internally performs the following steps:
282
322
1. Creates a new fragment with the specified payload.
@@ -318,7 +358,7 @@ _regression_ field is dropped in the response.
*`is_sortable`: Whether the field is sortable. Requires `is_filterable` to be true.
392
432
*`is_groupable`: Whether the field is groupable. Requires `is_filterable` to be true.
393
433
*`order`: The order in which the field appears in the side panel.
394
-
*`group_name`: The group title under which field(s) appear in the side panel. In the example below, the fields are grouped under groups titled **Group 1** and **Group 2**.
434
+
*`group_name`: The group title under which field(s) appear in the side panel. In the
435
+
example below, the fields are grouped under groups titled **Group 1** and **Group 2**.
0 commit comments