https://linear.app/unleash/issue/2-1253/add-support-for-more-events-in-the-slack-app-integration
Adds support for a lot more events in our integrations. Here is how the
full list looks like:
- ADDON_CONFIG_CREATED
- ADDON_CONFIG_DELETED
- ADDON_CONFIG_UPDATED
- API_TOKEN_CREATED
- API_TOKEN_DELETED
- CHANGE_ADDED
- CHANGE_DISCARDED
- CHANGE_EDITED
- CHANGE_REQUEST_APPLIED
- CHANGE_REQUEST_APPROVAL_ADDED
- CHANGE_REQUEST_APPROVED
- CHANGE_REQUEST_CANCELLED
- CHANGE_REQUEST_CREATED
- CHANGE_REQUEST_DISCARDED
- CHANGE_REQUEST_REJECTED
- CHANGE_REQUEST_SENT_TO_REVIEW
- CONTEXT_FIELD_CREATED
- CONTEXT_FIELD_DELETED
- CONTEXT_FIELD_UPDATED
- FEATURE_ARCHIVED
- FEATURE_CREATED
- FEATURE_DELETED
- FEATURE_ENVIRONMENT_DISABLED
- FEATURE_ENVIRONMENT_ENABLED
- FEATURE_ENVIRONMENT_VARIANTS_UPDATED
- FEATURE_METADATA_UPDATED
- FEATURE_POTENTIALLY_STALE_ON
- FEATURE_PROJECT_CHANGE
- FEATURE_REVIVED
- FEATURE_STALE_OFF
- FEATURE_STALE_ON
- FEATURE_STRATEGY_ADD
- FEATURE_STRATEGY_REMOVE
- FEATURE_STRATEGY_UPDATE
- FEATURE_TAGGED
- FEATURE_UNTAGGED
- GROUP_CREATED
- GROUP_DELETED
- GROUP_UPDATED
- PROJECT_CREATED
- PROJECT_DELETED
- SEGMENT_CREATED
- SEGMENT_DELETED
- SEGMENT_UPDATED
- SERVICE_ACCOUNT_CREATED
- SERVICE_ACCOUNT_DELETED
- SERVICE_ACCOUNT_UPDATED
- USER_CREATED
- USER_DELETED
- USER_UPDATED
I added the events that I thought were relevant based on my own
discretion. Know of any event we should add? Let me know and I'll add it
🙂
For now I only added these events to the new Slack App integration, but
we can add them to the other integrations as well since they are now
supported.
The event formatter was refactored and changed quite a bit in order to
make it easier to maintain and add new events in the future. As a
result, events are now posted with different text. Do we consider this a
breaking change? If so, I can keep the old event formatter around,
create a new one and only use it for the new Slack App integration.
I noticed we don't have good 404 behaviors in the UI for things that are
deleted in the meantime, that's why I avoided some links to specific
resources (like feature strategies, integration configurations, etc),
but we could add them later if we improve this.
This PR also tries to add some consistency to the the way we log events.
In this PR we are adding a JSON Editor that will be used for `json`
variant payload type. Its using `vanilla-jsoneditor` package
https://www.npmjs.com/package/vanilla-jsoneditor and is lazy loaded only
when the `json` payload type is selected in the dropdown UI.
https://linear.app/unleash/issue/2-1235/docs-slack-app-integration-documentation
This adds a new reference doc for the new Unleash Slack App integration
and marks the previous Slack integration as deprecated.
As a side-effect this PR also fixes an issue where we wouldn't be able
to delete tags with special characters.
---------
Co-authored-by: David Leek <david@getunleash.io>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
We love all open-source Unleash users. in 2022 we built the [segment
capability](https://docs.getunleash.io/reference/segments) (v4.13) as an
enterprise feature, simplify life for our customers.
Now it is time to contribute it to the world 🌏
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
## About the changes
Adds optional support for specifying JSON templates for datadog message
payload
![image](https://github.com/Unleash/unleash/assets/707867/eb7c838a-7abf-441e-972e-ddd7ada07efa)
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
`frontend/src/component/integrations/IntegrationForm/IntegrationParameters/IntegrationParameter/IntegrationParameterEnableWithDropdown.tsx`
- a new component comprising of a text field and a dropdown menu
`src/lib/addons/datadog.ts` - Where the integration is taking place
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
- Should I have implemented the new component type as a specifiable
addon parameter type in definitions? Felt a bit YAGNI/Premature
- Would like input on naming and the new component etc
https://linear.app/unleash/issue/2-1401/misc-fixes-and-improvements-related-to-the-new-slack-app-integration
This includes multiple UI-related misc fixes and improvements that are
not only related with the new Slack App integration but also
integrations in general.
- Improves the styling in the "how does it work" section;
- Improves the text in the `IntegrationMultiSelector`s;
- Switches "Configure" and "Open" around to match designs;
- Properly handles click event on `IntegrationCardMenu` (fix navigation
on dialog click);
- Fixes titles and contents for "enable/disable" and "delete"
integration dialogs to match designs;
- Updates Slack App integration "how does it work" section to better
reflect the intended behavior;
- Removes redundant alerts after previous point;
- Adds an alert in the old Slack integration configuration warning of
its deprecation and suggesting the new Slack App integration instead;
- Fixes typos;
- Slight refactors;
![image](https://github.com/Unleash/unleash/assets/14320932/17b09742-f00b-4be2-829f-8248ffe67996)
Co-authored by @nicolaesocaciu
Previously, the front end would show info about the pattern if it
exists, regardless of whether the feature is active or not. The
pattern wouldn't be enforced, but it's confusing anyway, so let's hide
it.
Input should use state set outside and derive "all selected" from it.
This was not the case causing issues when loading a form with "wildcard"
pre-selected.
Fix issues uncovered when reviewing integrations list and form.
- YouTube CSP
- Text content and formatting
- Margins
- Update old integration icons
- Fix headers in dark theme
This PR adds plausible metrics for feature naming patterns. The changes
are tracked whenever the form is submitted and the naming pattern has
changed. We track three different actions:
- added :: if there was no pattern before and now there is one
- removed :: if there was a pattern before and now there is none
- changed :: if there was a pattern before and now there is a different
one
The corresponding event type has been created in plausible.
This PR simplifies the flag naming tooltip considerably. It now only
contains an example of a pattern and what it will match. It also updates
the link in the form section description to point directly to a regex
cheat sheet instead of a general regex reference document.
There's a few reasons for doing this:
1. The text preceding the input already explains what the pattern does
and explains that it is a regex.
2. The text preceding the input also contains a link to a regex cheat
sheet (which is arguably a better place to explain regexes than a
tooltip).
3. The tooltip was very long. While a lot of the information there was
useful, it would also be hard to use. Imagine a user checking the
tooltip, scrolling all the way down, but accidentally moving the mouse a
bit and the tooltip disappearing. They would have to scroll all the way
down again. Or maybe they need to remember what it was they just looked
at. It would be more useful to have the information on a separate page.
4. The tooltip is not accessible by keyboard. This means that users who
use a keyboard to navigate the UI would not be able to scroll or
otherwise navigate the tooltip, potentially leaving them in the dark.
![image](https://github.com/Unleash/unleash/assets/17786332/88a74ad9-181a-44ba-9eb9-4818c081442f)
This PR adds:
* Generated types for useProjectDoraMetrics
* Mobile enhancements
* Tooltips
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
This PR updates the UI to reflect the changes to the implicit ^ and $
that we now add. The changes are:
1. Show input adornments for ^ and $ when you create a pattern.
2. Mention that ^ and $ are added implicitly in description.
3. Checks the example you provide against the pattern with added ^ and $
+ adds a test for that.
Points 1 and 2:
![image](https://github.com/Unleash/unleash/assets/17786332/88c610b4-444b-4a83-a50a-4b7639614a86)
## Discussion point:
I have not touched the information about the pattern yet as the PR that
updates that is still in review (#4656), but it would be prudent to also
update that info to make it clearer. I can address that in a follow-up
PR.