mirror of
https://github.com/Unleash/unleash.git
synced 2025-07-26 13:48:33 +02:00
Events docs revamp (#8360)
This commit is contained in:
Melinda Fekete
GitHub
parent
8f4454039a
commit
8736d2a916
@ -348,15 +348,15 @@ Because a feature flag service controls how an application behaves in production
|
||||
|
||||
Unleash provides the data to log any change over time at the flag level and at the project level. Logs are useful for downstream data warehouses or data lakes. Tools like [Splunk](https://www.splunk.com/) can help you combine logs and run advanced queries against them.
|
||||
|
||||
For our Python app, we can view Event logs to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
For our Python app, we can view events in [Event Log](/reference/events#event-log) to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
|
||||
- When the flag was created
|
||||
- How the gradual rollout strategy was configured
|
||||
- When and how the variants were created and configured
|
||||
|
||||
|
||||
|
||||
|
||||
You can also retrieve event log data by using an API command below:
|
||||
You can also retrieve events by using an API command below:
|
||||
|
||||
```py
|
||||
import requests
|
||||
@ -374,7 +374,7 @@ response = requests.request("GET", url, headers=headers, data=payload)
|
||||
print(response.text)
|
||||
```
|
||||
|
||||
Read our documentation on [Event logs](/reference/event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
Read our documentation on [Event Log](/reference/events#event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
|
||||
## Flag Automation and Workflow Integration for Django Apps
|
||||
|
||||
|
||||
@ -312,15 +312,15 @@ This is especially true in very regulated environments like health care, insuran
|
||||
|
||||
Unleash provides the data to log any change over time at the flag level and at the project level. Logs are useful for downstream data warehouses or data lakes.
|
||||
|
||||
You can view Event logs to monitor the changes to flag strategies and statuses, like:
|
||||
You can view [Event Log](/reference/events#event-log) to monitor the changes to flag strategies and statuses, like:
|
||||
|
||||
- When the flag was created
|
||||
- How the gradual rollout strategy was configured
|
||||
- When and how the variants were created and configured
|
||||
|
||||
|
||||
|
||||
|
||||
You can also retrieve event logs by using an API command, like below:
|
||||
You can also retrieve events by using an API command, like below:
|
||||
|
||||
```csharp
|
||||
HttpClient client = new HttpClient();
|
||||
@ -336,7 +336,7 @@ var responseBody = await response.Content.ReadAsStringAsync();
|
||||
Console.WriteLine(responseBody);
|
||||
```
|
||||
|
||||
Read our documentation on [Event logs](/reference/event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
Read our documentation on [Event Log](/reference/events#event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
|
||||
## Flag Automation and Workflow Integration for .NET Apps
|
||||
|
||||
|
||||
@ -274,15 +274,15 @@ Because a feature flag service controls how an application behaves in production
|
||||
|
||||
Unleash provides the data to log any change over time at the flag level and at the project level. Logs are useful for downstream data warehouses or data lakes. Tools like [Splunk](https://www.splunk.com/) can help you combine logs and run advanced queries against them.
|
||||
|
||||
For our iOS app, we can view Event logs to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
For our iOS app, we can view events in [Event Log](/reference/events#event-log) to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
|
||||
- When the flag was created
|
||||
- How the gradual rollout strategy was configured
|
||||
- When and how the variants were created and configured
|
||||
|
||||
|
||||
|
||||
|
||||
You can also retrieve event log data by using an API command below:
|
||||
You can also retrieve events by using the API command below:
|
||||
|
||||
```
|
||||
curl -L -X GET '<your-unleash-url>/api/admin/events/:featureName' \
|
||||
@ -290,7 +290,7 @@ curl -L -X GET '<your-unleash-url>/api/admin/events/:featureName' \
|
||||
-H 'Authorization: <API_KEY_VALUE>'
|
||||
```
|
||||
|
||||
Read our documentation on [Event logs](/reference/event-log) and [APIs](/reference/api/unleash/events) to learn more.
|
||||
Read our documentation on [Event Log](/reference/events#event-log) and [APIs](/reference/api/unleash/events) to learn more.
|
||||
|
||||
## Change Management & Feature Flag Approvals in iOS
|
||||
|
||||
|
||||
@ -216,15 +216,15 @@ Because a feature flag service controls how an application behaves in production
|
||||
|
||||
Unleash provides the data to log any change over time at the flag level and the project level. Logs are useful for downstream data warehouses or data lakes. Tools like Splunk can help you combine logs and run advanced queries against them.
|
||||
|
||||
For our Spring Boot app, we can view Event logs to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
For our Spring Boot app, we can view events in [Event Log](/reference/events#event-log) to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
|
||||
- When the flag was created
|
||||
- How the gradual rollout strategy was configured
|
||||
- When and how the variants were created and configured
|
||||
|
||||
|
||||
|
||||
|
||||
You can also retrieve event log data by using an API command. Read our documentation on [Event logs](/reference/event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
You can also retrieve events by using an API command. Read our documentation on [Event Log](/reference/events#event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
|
||||
## Flag Automation & Workflow Integration for Java Apps
|
||||
|
||||
|
||||
@ -347,15 +347,15 @@ Because a feature flag service controls how an application behaves in production
|
||||
|
||||
Unleash provides the data to log any change over time at the flag level and at the project level. Logs are useful for downstream data warehouses or data lakes. Tools like [Splunk](https://www.splunk.com/) can help you combine logs and run advanced queries against them.
|
||||
|
||||
For our Python app, we can view Event logs to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
For our Python app, we can view events in [Event Log](/reference/events#event-log) to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
|
||||
- When the flag was created
|
||||
- How the gradual rollout strategy was configured
|
||||
- When and how the variants were created and configured
|
||||
|
||||
|
||||
|
||||
|
||||
You can also retrieve event log data by using an API command below:
|
||||
You can also retrieve events by using the API command below:
|
||||
|
||||
```py
|
||||
import requests
|
||||
@ -373,7 +373,7 @@ response = requests.request("GET", url, headers=headers, data=payload)
|
||||
print(response.text)
|
||||
```
|
||||
|
||||
Read our documentation on [Event logs](/reference/event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
Read our documentation on [Event Log](/reference/events#event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
|
||||
## Flag Automation & Workflow Integration for Python Apps
|
||||
|
||||
|
||||
@ -309,15 +309,15 @@ This is especially true in very regulated environments like health care, insuran
|
||||
|
||||
Unleash provides the data to log any change over time at the flag level and at the project level. Logs are useful for downstream data warehouses or data lakes.
|
||||
|
||||
You can view Event logs to monitor the changes to flag strategies and statuses, like:
|
||||
You can view events in [Event Log](/reference/events#event-log) to monitor the changes to flag strategies and statuses, like:
|
||||
|
||||
- When the flag was created
|
||||
- How the gradual rollout strategy was configured
|
||||
- When and how the variants were created and configured
|
||||
|
||||
|
||||
|
||||
|
||||
You can also retrieve event logs by using an API command, like below:
|
||||
You can also retrieve events by using an API command, like below:
|
||||
|
||||
```ruby
|
||||
require 'httpx'
|
||||
@ -333,7 +333,7 @@ response = HTTPX.get(url, headers: headers)
|
||||
puts response.body
|
||||
```
|
||||
|
||||
Read our documentation on [Event logs](/reference/event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
Read our documentation on [Event Log](/reference/events#event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
|
||||
## Flag Automation and Workflow Integration for Rails Apps
|
||||
|
||||
|
||||
@ -400,15 +400,15 @@ Fortunately, this is straightforward in Unleash Enterprise.
|
||||
|
||||
Unleash provides the data to log any change that has happened over time, at the flag level from a global level. In conjunction with Unleash, tools like [Splunk](https://www.splunk.com/) can help you combine logs and run advanced queries against them. Logs are useful for downstream data warehouses or data lakes.
|
||||
|
||||
In our React tutorial application, we can view Event logs to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
For our React tutorial application, we can view events in [Event Log](/reference/events#event-log) to monitor the changes to flag strategies and statuses we have made throughout our examples, such as:
|
||||
|
||||
- When the `newNotificationsBadge` flag was created
|
||||
- How the gradual rollout strategy was configured
|
||||
- When and how the variants were created and configured
|
||||
|
||||
|
||||
|
||||
|
||||
You can also retrieve event log data by using an API command below:
|
||||
You can also retrieve events by using the API command below:
|
||||
|
||||
```
|
||||
curl -L -X GET '<your-unleash-url>/api/admin/events/:featureName' \
|
||||
@ -416,7 +416,7 @@ curl -L -X GET '<your-unleash-url>/api/admin/events/:featureName' \
|
||||
-H 'Authorization: <API_KEY_VALUE>'
|
||||
```
|
||||
|
||||
Read our documentation on [Event logs](/reference/event-log) and [APIs](/reference/api/unleash/events) to learn more.
|
||||
Read our documentation on [Event Log](/reference/events#event-log) and [APIs](/reference/api/unleash/events) to learn more.
|
||||
|
||||
## Change Management & Feature Flag Approvals in React
|
||||
|
||||
|
||||
@ -308,15 +308,15 @@ This is especially true in very regulated environments like health care, insuran
|
||||
|
||||
Unleash provides the data to log any change over time at the flag level and at the project level. Logs are useful for downstream data warehouses or data lakes.
|
||||
|
||||
You can view Event logs to monitor the changes to flag strategies and statuses, like:
|
||||
You can view [Event Log](/reference/events#event-log) to monitor the changes to flag strategies and statuses, like:
|
||||
|
||||
- When the flag was created
|
||||
- How the gradual rollout strategy was configured
|
||||
- When and how the variants were created and configured
|
||||
|
||||
|
||||
|
||||
|
||||
You can also retrieve event logs by using an API command, like below:
|
||||
You can also retrieve events by using an API command, like below:
|
||||
|
||||
```ruby
|
||||
require 'httpx'
|
||||
@ -332,7 +332,7 @@ response = HTTPX.get(url, headers: headers)
|
||||
puts response.body
|
||||
```
|
||||
|
||||
Read our documentation on [Event logs](/reference/event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
Read our documentation on [Event Log](/reference/events#event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
|
||||
## Flag Automation & Workflow Integration for Ruby Apps
|
||||
|
||||
|
||||
@ -372,15 +372,15 @@ This is especially true in very regulated environments like health care, insuran
|
||||
|
||||
Unleash provides the data to log any change over time at the flag level and at the project level. Logs are useful for downstream data warehouses or data lakes.
|
||||
|
||||
You can view Event logs to monitor the changes to flag strategies and statuses, like:
|
||||
You can view events in [Event Log](/reference/events#event-log) to monitor the changes to flag strategies and statuses, like:
|
||||
|
||||
- When the flag was created
|
||||
- How the gradual rollout strategy was configured
|
||||
- When and how the variants were created and configured
|
||||
|
||||
|
||||
|
||||
|
||||
You can also retrieve event logs by using an API command, like below:
|
||||
You can also retrieve events by using an API command, like below:
|
||||
|
||||
```rust
|
||||
use reqwest::blocking::Client;
|
||||
@ -406,7 +406,7 @@ fn main() -> Result<(), Box<dyn Error>> {
|
||||
}
|
||||
```
|
||||
|
||||
Read our documentation on [Event logs](/reference/event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
Read our documentation on [Event Log](/reference/events#event-log) and [APIs](/reference/api/unleash/get-events-for-toggle) to learn more.
|
||||
|
||||
## Flag Automation and Workflow Integration for Rust Apps
|
||||
|
||||
|
||||
@ -164,9 +164,9 @@ Fortunately, this is straightforward in Unleash Enterprise.
|
||||
|
||||
Unleash provides the data to log any change that has happened over time, at the flag level from a global level. In conjunction with Unleash, tools like Splunk can help you combine logs and run advanced queries against them. Logs are useful for downstream data warehouses or data lakes.
|
||||
|
||||
|
||||
|
||||
|
||||
Learn more about [event logs](/reference/event-log/) in our documentation.
|
||||
Learn more about [Event Log](/reference/events#event-log/) in our documentation.
|
||||
|
||||
### Managing Change Requests
|
||||
|
||||
|
||||
@ -28,9 +28,9 @@ curl -X POST -H "Content-Type: application/json" \
|
||||
https://app.unleash-hosted.com/demo/api/admin/features/Demo/toggle/on
|
||||
```
|
||||
|
||||
**Great success!** We have now enabled the feature flag. We can also verify that it was actually changed by the API user by navigating to the Event log (history) for this feature flag.
|
||||
**Great success!** We have now enabled the feature flag. We can also verify that it was actually changed by the API user by navigating to [Event Log](/reference/events#event-log) and filtering events for this feature flag.
|
||||
|
||||
|
||||
|
||||
|
||||
## API overview {#api-overview}
|
||||
|
||||
|
||||
@ -46,7 +46,7 @@ Filters are completely optional, so if you don't configure any filter your actio
|
||||
|
||||
### Actions
|
||||
|
||||
When these actions are triggered, they will execute under the identity of a [service account](./service-accounts.md). This means that when you later check the [event log](./event-log) you will see this service account as the actor for those events. In order to execute the configured actions successfully, this service account needs to have the necessary permissions. This service account doesn't need an API token, so when creating it you can skip the token generation step and simply make sure it has the necessary permissions.
|
||||
When these actions are triggered, they execute using the identity of a [service account](./service-accounts.md). As a result, when you later view events in [Event Log](./events#event-log), you’ll see this service account listed as the actor for those events. In order to execute the configured actions successfully, this service account needs to have the necessary permissions. This service account doesn't need an API token, so when creating it you can skip the token generation step and simply make sure it has the necessary permissions.
|
||||
|
||||
The actions are executed in the same order that they are defined. If a previous action fails, the following actions will not be started. You can add multiple actions to an action set and you can add multiple action sets to a project. Depending on the action you want to execute you will have to provide different parameters.
|
||||
|
||||
|
||||
@ -82,7 +82,7 @@ We do not recommend using admin tokens anymore, they are not connected to any us
|
||||
|
||||
**Personal access tokens** are a special form of admin tokens and grant access to the same resources that the user that created them has access to. These permissions are dynamic, so if a user's permissions change through addition of a custom role, the token will likewise have altered permissions.
|
||||
|
||||
When using a personal access token to modify resources, the event log will list the token creator's name for that operation.
|
||||
When you use a personal access token to modify resources, the events record the token creator's name for that operation.
|
||||
|
||||
Personal access tokens with a lifetime **will stop working after the expiration date**.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ In order to access the admin API endpoints you need to identify yourself. Unless
|
||||
|
||||
:::
|
||||
|
||||
The Events API lets you retrieve [events](/reference/event-types.mdx) from your Unleash instance.
|
||||
The Events API lets you retrieve [events](/reference/events.mdx) from your Unleash instance.
|
||||
|
||||
## Event endpoints
|
||||
|
||||
@ -131,6 +131,6 @@ The list of events related to the given toggle.
|
||||
|
||||
:::note Content moved
|
||||
|
||||
This section has been moved to a dedicated [event type reference document](/reference/event-types.mdx).
|
||||
This section has been moved to a dedicated [events documentation](/reference/events.mdx).
|
||||
|
||||
:::
|
||||
|
||||
@ -1,21 +0,0 @@
|
||||
---
|
||||
title: Event Log
|
||||
---
|
||||
|
||||
The event log lets you track changes in Unleash. It lists _what_ changed, _when_ it changed, and _who_ performed the change.
|
||||
|
||||
## Feature flag log {#event-log-per-feature-toggle}
|
||||
|
||||
<span id="audit-log-per-feature-flag" data-reason="backwards-compatibility"></span>
|
||||
|
||||
Each feature flag has its own event log. The event log is available under the "Event log" tab in the tab view.
|
||||
|
||||
|
||||
|
||||
## Global Event Log {#global-event-log}
|
||||
|
||||
<span id="global-audit-log" data-reason="backwards-compatibility"></span>
|
||||
|
||||
Unleash also keeps an event log across all flags and activation strategies, tracking all changes. You access the global event log via the “event log”, which you can find in the drawer menu. The global event log is only accessible by users with instance admin access.
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
725
website/docs/reference/events.mdx
Normal file
725
website/docs/reference/events.mdx
Normal file
@ -0,0 +1,725 @@
|
||||
---
|
||||
title: Events
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Events help you keep track of changes across your Unleash instance. You can explore events in [Event Log](#event-log) or using the global [Event Timeline](#event-timeline).
|
||||
|
||||
The Event Log provides a full list of all events, whereas the Event Timeline offers a highlight of recent key events and [Signals](/reference/signals) from external sources.
|
||||
You can use Event Log for auditing purposes, while Event Timeline is particularly helpful for debugging recent changes and their impact.
|
||||
|
||||
## Event Log
|
||||
|
||||
The Event Log lists all events in your Unleash instance. You can search and filter events by date range, event type, project, feature flag, and user. You can also export events as CSV or JSON files.
|
||||
|
||||
To access events in the Admin UI, you need Admin access. To view all events, go to **Admin > Event log**. To view events for a specific feature flag, go to the **Event log** tab on that feature flag's page.
|
||||
|
||||
Each [event type](#event-types) contains different data, but all events follow the same schema:
|
||||
|
||||
|
||||
| Field | Type | Description |
|
||||
|--------------------|--------|-------------------------------------------------------------------|
|
||||
| `id`* | number | Unique identifier for the event; incremental whole number. |
|
||||
| `type`* | string | Describes the type of event (e.g., `feature-strategy-update`). |
|
||||
| `createdAt`* | string | Timestamp when the event was created; ISO 8601 format. |
|
||||
| `createdBy`* | string | Email of the user who triggered the event. |
|
||||
| `createdByUserId` | number | Unique identifier of the user who triggered the event. |
|
||||
| `data` | object | Details about the event (e.g., feature strategy, API token data). |
|
||||
| `preData` | object | Previous state before the event. |
|
||||
| `tags` | array | Array of tags associated with the event. |
|
||||
| `featureName` | string | Name of the feature flag associated with the event. |
|
||||
| `project` | string | Name of the project involved in the event. |
|
||||
| `environment` | string | Environment related to the event (e.g., `development`). |
|
||||
| `label` | string | Brief description of the event. |
|
||||
| `summary` | string | Markdown formatted summary of the event. |
|
||||
|
||||
|
||||
Fields marked with an asterisk (*) are always returned in the event schema. Other fields may be optional or have null values, depending on the event type.
|
||||
|
||||
See the [feature-created event type](#feature-created) for an example event.
|
||||
|
||||
|
||||
## Event Timeline
|
||||
|
||||
:::note Availability
|
||||
|
||||
**Plan**: [Enterprise](https://www.getunleash.io/plans/enterprise) | **Version**: `6.3+` in BETA
|
||||
|
||||
:::
|
||||
|
||||
Event Timeline highlights recent events across all your projects in one unified timeline. You can access the timeline from the top menu in the Admin UI.
|
||||
|
||||
|
||||
|
||||
The timeline shows key events and signals for up to 48 hours per environment and is designed to help you get an overview of changes and quickly identify and debug any issues. You can switch between different time spans to focus on recent activity.
|
||||
Although you can filter events by environment, the timeline also shows environment-agnostic events, such as archiving a feature flag.
|
||||
|
||||
You can enable or disable the timeline view at any time based on your preferences. Events that occur close together in time are automatically grouped, but hovering over an event group shows detailed information about the specific events.
|
||||
|
||||
## Event types
|
||||
|
||||
### Feature flag events
|
||||
|
||||
Events related to feature flags and their life cycle.
|
||||
|
||||
#### `feature-created`
|
||||
|
||||
Generated when you create a feature flag. The `data` property contains the details for the new feature flag.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27332,
|
||||
"type": "feature-created",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"name": "test-flag",
|
||||
"description": null,
|
||||
"type": "release",
|
||||
"project": "test-project",
|
||||
"stale": false,
|
||||
"createdAt": "2024-10-03T11:09:53.201Z",
|
||||
"lastSeenAt": null,
|
||||
"impressionData": false,
|
||||
"archivedAt": null,
|
||||
"archived": false
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": "test-flag",
|
||||
"project": "test-project",
|
||||
"environment": null,
|
||||
"label": "Flag created",
|
||||
"summary": "**user@getunleash.io** created **test-flag** in ... "
|
||||
}
|
||||
```
|
||||
|
||||
#### `feature-deleted`
|
||||
|
||||
Generated when you delete a feature flag. The `preData` property contains the deleted feature flag data.
|
||||
|
||||
#### `feature-archived`
|
||||
|
||||
Generated when you archive a feature flag. `preData` and `data` are null.
|
||||
|
||||
#### `feature-revived`
|
||||
|
||||
Generated when you revive an archived feature flag. `preData` and `data` are null.
|
||||
|
||||
#### `feature-metadata-updated`
|
||||
|
||||
Generated when a feature flag's metadata, such as description, flag type, or impression data settings, are changed. The `data` property contains the new flag data. The `preData` property contains the flag's previous data.
|
||||
|
||||
#### `feature-project-change`
|
||||
|
||||
Generated when you move a feature flag from one project to another. The `data` property contains the names of the old and the new project.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27332,
|
||||
"type": "feature-project-change",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"newProject": "test-project",
|
||||
"oldProject": "old-test-project"
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": "test-flag",
|
||||
"project": "test-project",
|
||||
"environment": null,
|
||||
"label": "Flag moved to a new project",
|
||||
"summary": "**user@getunleash.io** moved **test-flag** from ... "
|
||||
}
|
||||
```
|
||||
|
||||
#### `feature-import`
|
||||
|
||||
Generated when you import a feature flag as part of an import process. The `data` property contains the feature flag data. See [feature-created](#feature-created) for an example.
|
||||
|
||||
#### `feature-tagged`
|
||||
|
||||
Generated when you add a tag to a feature flag. The `data` property contains the new tag.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27333,
|
||||
"type": "feature-tagged",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"type": "simple",
|
||||
"value": "tag2"
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [
|
||||
{
|
||||
"type": "simple",
|
||||
"value": "tag2"
|
||||
}
|
||||
],
|
||||
"featureName": "test-flag",
|
||||
"project": "test-project",
|
||||
"environment": null,
|
||||
"label": "Flag tagged",
|
||||
"summary": "**user@getunleash.io** tagged **test-flag** with ... "
|
||||
}
|
||||
```
|
||||
|
||||
#### `feature-untagged`
|
||||
|
||||
Generated when you remove a tag from a feature flag. The `data` property contains the tag that was removed. See [feature-tagged](#feature-tagged) for an example.
|
||||
|
||||
#### `feature-tag-import`
|
||||
|
||||
Generated when you import a tagged feature flag as part of an import job. The `data` property contains the name of the feature and the tag.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27334,
|
||||
"type": "feature-tag-import",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"featureName": "new-feature",
|
||||
"tag": {
|
||||
"type": "simple",
|
||||
"value": "tag1"
|
||||
}
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null,
|
||||
"label": null,
|
||||
"summary": null
|
||||
}
|
||||
```
|
||||
|
||||
#### `feature-strategy-add`
|
||||
|
||||
Generated when you add a strategy to a feature flag. The `data` property contains the configuration for the new strategy.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27335,
|
||||
"type": "feature-strategy-add",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"id": "3f4bf713-696c-43a4-8ce7-d6c607108858",
|
||||
"name": "flexibleRollout",
|
||||
"title": null,
|
||||
"disabled": false,
|
||||
"parameters": {
|
||||
"groupId": "new-feature",
|
||||
"rollout": "67",
|
||||
"stickiness": "default"
|
||||
},
|
||||
"variants": [],
|
||||
"sortOrder": 0,
|
||||
"segments": []
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": "new-feature",
|
||||
"project": "my-other-project",
|
||||
"environment": "default",
|
||||
"label": "Flag strategy added",
|
||||
"summary": "**user@getunleash.io** added strategy"
|
||||
}
|
||||
```
|
||||
|
||||
#### `feature-strategy-update`
|
||||
|
||||
Generated when you update a feature flag strategy. The `data` property contains the new strategy configuration. The `preData` property contains the previous strategy configuration.
|
||||
|
||||
#### `feature-strategy-remove`
|
||||
|
||||
Generated when you remove a strategy from a feature flag. The `preData` contains the configuration of the strategy that was removed.
|
||||
|
||||
|
||||
#### `feature-stale-on`
|
||||
|
||||
Generated when you mark a feature flag as stale. `preData` and `data` are null.
|
||||
|
||||
#### `feature-stale-off`
|
||||
|
||||
Generated when you mark a stale feature flag as no longer stale. `preData` and `data` are null.
|
||||
|
||||
#### `feature-environment-enabled`
|
||||
|
||||
Generated when you enable an environment for a feature flag. The `environment` property contains the name of the environment, `preData` and `data` are null.
|
||||
|
||||
#### `feature-environment-disabled`
|
||||
|
||||
Generated when you disable an environment for a feature. The `environment` property contains the name of the environment. `preData` and `data` are null.
|
||||
|
||||
#### `drop-features`
|
||||
|
||||
Generated when you delete existing features as part of an import job. The `data.name` property is `"all-features"`.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27336,
|
||||
"type": "drop-features",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"name": "all-features"
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null
|
||||
}
|
||||
```
|
||||
|
||||
#### `drop-feature-tags`
|
||||
|
||||
Generated when you drop all existing tags as part of a configuration import. The `data.name` is `"all-feature-tags"`. See [drop-features](#drop-features) for an example.
|
||||
|
||||
#### `feature-potentially-stale-on`
|
||||
|
||||
Generated when Unleash marks a feature flag as potentially stale due to exceeding the expected lifetime of its [feature flag type](/reference/feature-toggle-types). `preData` and `data` are null.
|
||||
|
||||
#### `feature-updated`
|
||||
|
||||
:::caution Deprecated functionality
|
||||
|
||||
Deprecated in Unleash 4.3. Use more granular events, such as `feature-strategy-update`, instead.
|
||||
|
||||
:::
|
||||
|
||||
### Strategy events
|
||||
|
||||
#### `strategy-created`
|
||||
|
||||
Generated when you create a strategy. The `data` property contains the strategy configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 273357,
|
||||
"type": "strategy-created",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"name": "new-strategy",
|
||||
"description": "this strategy does ...",
|
||||
"parameters": [],
|
||||
"editable": true,
|
||||
"deprecated": false
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null,
|
||||
"label": "strategy-created",
|
||||
"summary": "**user@getunleash.io** triggered **strategy-created**"
|
||||
}
|
||||
```
|
||||
|
||||
#### `strategy-updated`
|
||||
|
||||
Generated when you change a strategy's configuration. The `data` property contains the new strategy configuration. See [strategy-created](#strategy-created) for an example.
|
||||
|
||||
#### `strategy-deleted`
|
||||
|
||||
Generated when you delete a strategy. The `data` property contains the name of the deleted strategy, `preData` is null.
|
||||
|
||||
#### `strategy-deprecated`
|
||||
|
||||
Generated when you deprecate a strategy. The `data` property contains the name of the deprecated strategy, `preData` is null.
|
||||
|
||||
#### `strategy-reactivated`
|
||||
|
||||
Generated when you reactivate a deprecated strategy. The `data` property contains the name of the reactivated strategy, `preData` is null.
|
||||
|
||||
#### `strategy-import`
|
||||
|
||||
Generated when you import a strategy as part of an import job. The `data` property contains the strategy's configuration, `preData` is null. See [strategy-created](#strategy-created) for an example.
|
||||
|
||||
#### `drop-strategies`
|
||||
|
||||
Generated when you delete existing strategies as part of an import job. The `data.name` property is `"all-strategies"`.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27338,
|
||||
"type": "drop-strategies",
|
||||
"createdBy": "import-API-token",
|
||||
"createdAt": "2022-06-03T11:30:40.579Z",
|
||||
"data": {
|
||||
"name": "all-strategies"
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null
|
||||
}
|
||||
```
|
||||
|
||||
### Context field events
|
||||
|
||||
#### `context-field-created`
|
||||
|
||||
Generated when you create a context field. The `data` property contains the context field configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27339,
|
||||
"type": "context-field-created",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"name": "new-context-field",
|
||||
"description": "this context field is for describing events",
|
||||
"legalValues": [],
|
||||
"stickiness": false
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null,
|
||||
"label": "Context field created",
|
||||
"summary": "**user@getunleash.io** created context field **new-context-field**"
|
||||
}
|
||||
```
|
||||
|
||||
#### `context-field-updated`
|
||||
|
||||
Generated when you update a context field. The `data` property contains the new context field configuration. See [context-field-created](#context-field-created) for an example.
|
||||
|
||||
#### `context-field-deleted`
|
||||
|
||||
Generated when you delete a context field. The `data` property contains the name of the deleted context field.
|
||||
|
||||
### Project events
|
||||
|
||||
#### `project-created`
|
||||
|
||||
Generated when you create a project. The `data` property contains the project configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27340,
|
||||
"type": "project-created",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"id": "my-other-project",
|
||||
"name": "my other project",
|
||||
"description": "a project for important work",
|
||||
"defaultStickiness": "default",
|
||||
"mode": "private",
|
||||
"changeRequestEnvironments": []
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": "my-other-project",
|
||||
"environment": null,
|
||||
"label": "Project created",
|
||||
"summary": "**user@getunleash.io** created project **my-other-project** ..."
|
||||
}
|
||||
```
|
||||
|
||||
#### `project-updated`
|
||||
|
||||
Generated when you update a project's configuration. The `data` property contains the new project configuration. The `preData` property contains the previous project configuration.
|
||||
|
||||
#### `project-deleted`
|
||||
|
||||
Generated when you delete a project. The `project` property contains the name of the deleted project.
|
||||
|
||||
#### `project-import`
|
||||
|
||||
Generated when you import a project. The `data` property contains the project's configuration details. See [project-created](#project-created) for an example.
|
||||
|
||||
#### `drop-projects`
|
||||
|
||||
Generated when you delete existing projects as part of an import job. The `data.name` property is `"all-projects"`.
|
||||
|
||||
### Tag events
|
||||
|
||||
#### `tag-created`
|
||||
|
||||
Generated when you create a new tag. The `data` property contains the tag that was created.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27341,
|
||||
"type": "tag-created",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"type": "6.1.0",
|
||||
"value": "release"
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null,
|
||||
"label": "tag-created",
|
||||
"summary": "**user@getunleash.io** triggered **tag-created**"
|
||||
}
|
||||
```
|
||||
|
||||
#### `tag-deleted`
|
||||
|
||||
Generated when you delete a tag. The `data` property contains the tag that was deleted. See [tag-created](#tag-created) for an example.
|
||||
|
||||
#### `tag-import`
|
||||
|
||||
Generated when you import a tag as part of an import job. The `data` property contains the imported tag. See [tag-created](#tag-created) for an example.
|
||||
|
||||
#### `drop-tags`
|
||||
|
||||
Generated when you delete existing tags as part of an import job. The `data.name` property is `"all-tags"`.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27342,
|
||||
"type": "drop-tags",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"name": "all-tags"
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null,
|
||||
"label": "drop-tags",
|
||||
"summary": "**user@getunleash.io** triggered **drop-tags**"
|
||||
}
|
||||
```
|
||||
|
||||
### Tag type events
|
||||
|
||||
#### `tag-type-created`
|
||||
|
||||
Generated when you create a new tag type. The `data` property contains the tag type configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27343,
|
||||
"type": "tag-type-created",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"name": "new-tag-type",
|
||||
"description": "event testing"
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null,
|
||||
"label": "tag-type-created",
|
||||
"summary": "**user@getunleash.io** triggered **tag-type-created**"
|
||||
}
|
||||
```
|
||||
|
||||
#### `tag-type-updated`
|
||||
|
||||
Generated when you update a tag type. The `data` property contains the new tag type configuration. See [tag-type-created](#tag-type-created) for an example.
|
||||
|
||||
#### `tag-type-deleted`
|
||||
|
||||
Generated when you delete a tag type. The `data` property contains the name of the deleted tag type.
|
||||
|
||||
#### `tag-type-import`
|
||||
|
||||
Generated when you import a tag type as part of an import job. The `data` property contains the imported tag. See [tag-type-created](#tag-type-created) for an example.
|
||||
|
||||
#### `drop-tag-types`
|
||||
|
||||
Generated when you drop all existing tag types as part of a configuration import. The `data.name` property is `"all-tag-types"`.
|
||||
|
||||
### Integration events
|
||||
|
||||
#### `addon-config-created`
|
||||
|
||||
Generated when you create an integration configuration. The `data` property contains the provider type.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27343,
|
||||
"type": "addon-config-created",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"id": 14,
|
||||
"provider": "webhook",
|
||||
"enabled": true,
|
||||
"description": "Test Webhooks",
|
||||
"events": [
|
||||
"feature-updated"
|
||||
],
|
||||
"projects": [
|
||||
"test-project"
|
||||
],
|
||||
"environments": [
|
||||
"production"
|
||||
]
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null,
|
||||
"label": "Integration configuration created",
|
||||
"summary": "**user@getunleash.io** created a new **webhook** integration configuration"
|
||||
}
|
||||
```
|
||||
|
||||
#### `addon-config-updated`
|
||||
|
||||
Generated when you update an integration configuration. The `data` property contains the `id` and `provider` of the integration.
|
||||
|
||||
|
||||
#### `addon-config-deleted`
|
||||
|
||||
Generated when you delete an integration configuration. The `data` property contains the `id` of the integration.
|
||||
|
||||
### User events
|
||||
|
||||
#### `user-created`
|
||||
|
||||
Generated when you create a new user. The `data` property contains the user's information.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27344,
|
||||
"type": "user-created",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"id": 111,
|
||||
"name": "New User Name",
|
||||
"email": "newuser@getunleash.io",
|
||||
"rootRole": 2
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null,
|
||||
"label": "User created",
|
||||
"summary": "**user@getunleash.io** created user **New User Name**"
|
||||
}
|
||||
```
|
||||
|
||||
#### `user-updated`
|
||||
|
||||
Generated when you update a user. The `data` property contains the updated user information; the `preData` property contains the previous state of the user's information.
|
||||
|
||||
|
||||
#### `user-deleted`
|
||||
|
||||
Generated when you delete a user. The `preData` property contains the deleted user's information.
|
||||
|
||||
### Environment events
|
||||
|
||||
#### `environment-import`
|
||||
|
||||
Generated when you import an environment as part of an import job. The `data` property contains the configuration of the imported environment.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27345,
|
||||
"type": "environment-import",
|
||||
"createdBy": "import-API-token",
|
||||
"createdAt": "2022-06-03T11:30:40.557Z",
|
||||
"data": {
|
||||
"name": "custom-environment",
|
||||
"type": "test",
|
||||
"sortOrder": 9999,
|
||||
"enabled": true,
|
||||
"protected": false
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": null,
|
||||
"environment": null
|
||||
}
|
||||
```
|
||||
|
||||
#### `drop-environments`
|
||||
|
||||
Generated when you delete existing environments as part of an import job. The `data.name` property is `"all-environments"`.
|
||||
|
||||
|
||||
### Segment events
|
||||
|
||||
#### `segment-created`
|
||||
|
||||
Generated when you create a segment. The `data` property contains the newly created segment.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 27346,
|
||||
"type": "segment-created",
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z",
|
||||
"createdByUserId": 110,
|
||||
"data": {
|
||||
"id": 5,
|
||||
"name": "new segment",
|
||||
"description": "this segment is for events",
|
||||
"project": "development",
|
||||
"constraints": [
|
||||
{
|
||||
"values": ["appA", "appB", "appC"],
|
||||
"inverted": false,
|
||||
"operator": "IN",
|
||||
"contextName": "appName",
|
||||
"caseInsensitive": false
|
||||
}
|
||||
],
|
||||
"createdBy": "user@getunleash.io",
|
||||
"createdAt": "2024-10-03T11:09:53.225Z"
|
||||
},
|
||||
"preData": null,
|
||||
"tags": [],
|
||||
"featureName": null,
|
||||
"project": "development",
|
||||
"environment": null,
|
||||
"label": "Segment created",
|
||||
"summary": "**user@getunleash.io** created segment **new segment**"
|
||||
}
|
||||
```
|
||||
|
||||
#### `segment-updated`
|
||||
|
||||
Generated when you update a segment's configuration. The `data` property contains the new segment configuration; the `preData` property contains the previous segment configuration.
|
||||
|
||||
|
||||
#### `segment-deleted`
|
||||
|
||||
Generated when you delete a segment. `preData` property contains the deleted segment.
|
||||
@ -67,7 +67,7 @@ The body template property is available from **Unleash 5.6** onwards.
|
||||
|
||||
:::
|
||||
|
||||
- **Body template** - This is an optional property. The template is used to override the body template used by Unleash when performing the HTTP POST. You can format your message using a [Mustache template](https://mustache.github.io). Refer to the [Unleash event types](/reference/event-types) reference to find out which event properties you have access to in the template.
|
||||
- **Body template** - This is an optional property. The template is used to override the body template used by Unleash when performing the HTTP POST. You can format your message using a [Mustache template](https://mustache.github.io). Refer to the [Unleash event types](/reference/events#event-types) reference to find out which event properties you have access to in the template.
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ Service account tokens allow service accounts to use the Admin API as themselves
|
||||
|
||||
These tokens act just like [personal access tokens](./api-tokens-and-client-keys.mdx#personal-access-tokens) for the service accounts, except that they are managed by Unleash admins.
|
||||
|
||||
When using a service account token to modify resources, the event log will display the service account name for that operation.
|
||||
When you use a service account token to modify resources, the events record the service account name for that operation.
|
||||
|
||||
Service account tokens can be managed by editing the respective service account:
|
||||
|
||||
|
||||
@ -336,11 +336,19 @@ module.exports = {
|
||||
},
|
||||
{
|
||||
from: '/advanced/audit_log',
|
||||
to: '/reference/event-log',
|
||||
to: '/reference/events',
|
||||
},
|
||||
{
|
||||
from: '/api/open_api',
|
||||
to: '/reference/api/unleash',
|
||||
from: '/advanced/audit_log',
|
||||
to: '/reference/events',
|
||||
},
|
||||
{
|
||||
from: '/reference/event-log',
|
||||
to: '/reference/events',
|
||||
},
|
||||
{
|
||||
from: '/reference/event-types',
|
||||
to: '/reference/events',
|
||||
},
|
||||
{
|
||||
from: '/advanced/api_access',
|
||||
|
||||
@ -324,8 +324,7 @@ module.exports = {
|
||||
'reference/custom-activation-strategies',
|
||||
'reference/dependent-features',
|
||||
'reference/environments',
|
||||
'reference/event-log',
|
||||
'reference/event-types',
|
||||
'reference/events',
|
||||
'reference/feature-flag-naming-patterns',
|
||||
'reference/feature-lifecycle',
|
||||
'reference/feature-toggles',
|
||||
|
||||
BIN
website/static/img/event-timeline.png
Normal file
BIN
website/static/img/event-timeline.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 62 KiB |
@ -43,7 +43,17 @@
|
||||
},
|
||||
{
|
||||
"source": "/advanced/audit_log",
|
||||
"destination": "/reference/event-log",
|
||||
"destination": "/reference/events",
|
||||
"permanent": true
|
||||
},
|
||||
{
|
||||
"source": "/reference/event-log",
|
||||
"destination": "/reference/events#event-log",
|
||||
"permanent": true
|
||||
},
|
||||
{
|
||||
"source": "/reference/event-types",
|
||||
"destination": "/reference/events#event-types",
|
||||
"permanent": true
|
||||
},
|
||||
{
|
||||
|
||||
Loading…
Reference in New Issue
Block a user