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
### 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;
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.
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:
## 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.
Adds `number` as possible payload type for variant.
Adds a flag to enable the feature
Updates all relevant models and schemas
Adds the option to the UI
Closes: #
[1-1357](https://linear.app/unleash/issue/1-1357/support-number-in-variant-payload)
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
Instead of this:
```ts
const { uiConfig } = useUiConfig();
const myFlag = Boolean(uiConfig?.flags?.myFlag)
```
we can have this:
```ts
const myFlag = useUiFlag("myFlag")
```
With the same type safety, less verbose and more purposeful code.
### Important files
- `frontend/src/hooks/useUiFlag.ts`
## Discussion points
Can we in the future share flags between frontend and backend? Right now
adding a new flag has to be done in 4 different places (backend flag
keys list, backend flags defaults config, backend experimental server
options, frontend type).
Most ergonomic option is to pull config directly from Unleash.
Issue, based on previous user feedback:
https://github.com/Unleash/unleash/issues/4565
Internal feature request document:
[docs.google.com/document/d/1Sx0q...](https://docs.google.com/document/d/1Sx0qKZXUVUCjuY5F4MOh1ieOM1A2_jE58zEA7jaM_1g/edit?usp=sharing)
