This PR describes in closer detail what happens when the user who
scheduled a change request is deleted. It mentions the new suspended
state and what the user can do to get out of it.
This change adds a mention of frontend API tokens to the docs. We've
had this functionality for a while, but it appears not to have been
documented.
Realized this as part of triaging #3005.
This commit updates the change request docs to talk about how the new
scheduled state works.
The subsection is marked as "in development", saying that it can
change at any moment until the feature is released.
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
We've made some first round updates to the React tutorial:
- making it more SEO-friendly with ordered lists, sequential language,
description of the JS library
- Switched over the demo app to point to an open source project:
[Cypress Real World
App](https://github.com/cypress-io/cypress-realworld-app)
- included best practice considerations for client-side development
- updated URL path to point to `/feature-flag-tutorials/react` for
simplification
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Would love feedback on if there's a need for more screenshots? Don't
want to be too screenshot-heavy though I imagine.
And need feedback on the descriptions of "Considerations for using
feature flags in react"
https://github.com/Unleash/unleash/compare/react-improvements?expand=1#diff-96d4956f49f80cd76489a72d4d88c2956ce9dcc695f66fe014ad1185e37cb589R21
Want to make sure that what I described makes sense or if it could use
some tweaking to convey the right message clearly.
## Why
Currently AWS API Gateway doesn't have compression enabled by default,
this PR will make it easier to for example deploy Unleash over to AWS
Lambda without further configuration in API Gateway, frameworks like
Serverless requires a bit more work to set up compression and some times
one might not need compression at all.
## How
Create a new config flag called `disableCompression` which will not
include `compression` middleware in express' instance when set as true.
A benefit of hosting your own edge instance is that it will be as close
to end users as you are.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Adding links to definition of what frontend api is. Can be confusing for
new users to read without seing what it is.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
## About the changes
Adding in an initial React tutorial with Unleash! This includes
installing Unleash, creating a React application with Vite, then
integrating Unleash to use with a CSS-focused feature toggle.
### Important files
- New File:
`website/docs/feature-flag-tutorials/react/implementing-feature-flags.md`
- Added new tutorial to navigation in `sidebars.js` and
`docusaurus.config.js`
There is a lot of room to make more advanced use case additions to this
React tutorial. For example, addressing SSR.
I think that'd be good for a future iteration to be helpful to the
community.
As discovered in the recent segments breakathon, the docs aren't very
clear about how conflicts are handled. This PR better documents when
they can't be deleted or moved. It also mentions the edge case where a
segment is used in an archived flag (it still can't be deleted, so you
must either delete the flag, or revive it and remove the segment)
https://linear.app/unleash/issue/2-1680/adr-specify-tables-when-querying-columns
This PR includes my suggestion of a "Specificity in database column
references" ADR.
The ADR proposes a standard for explicitly specifying the full table
name or alias for each column in our SQL queries, especially for queries
with joins between multiple tables. This decision is a direct response
to recent ambiguity errors encountered due to a database migration,
emphasizing the need for clearer SQL query standards in complex joins
and schema changes.
---------
Co-authored-by: Mateusz Kwasniewski <kwasniewski.mateusz@gmail.com>
See [Linear issue
2-1627](https://linear.app/unleash/issue/2-1627/db-permissions-update-docs-and-migration-guides).
Since we now use functions, we need more permissions than just GRANT ALL
PERMISSIONS ON DATBASE. In addition we need to be allowed to create
functions in the schema that's actually being used. This PR takes the
easy way out and say that we need OWNER privileges on the database. That
guarantees that we can do all we do in our migration scripts.
### Discussion points
We might encounter some pushback on this, if so, we'll need to say that
we need
`GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN <schema>` in addition to GRANT
ALL PRIVILEGES ON DATABASE, where <schema> is the schema selected in
their configuration.
We've been caught out here, we added a migration that used PG>=11
syntax, but our docs still state that we support v10, when it reached
EoL Nov 2022. This updates our docs to state v14 and newer, v14 came out
in 2021 and as such won't be EoL until 2026 according to [Postgres 5
year versioning scheme
support](https://www.postgresql.org/support/versioning/)
## About the changes
While working on Terraform I identified some issues with how our backend
handled some requests. This happened because the Terraform client was
unaware of new fields and was not sending them. This resulted in bad
behavior as some of those missing fields were treated in the backend as
`null` and removed existing data from the DB.
This ADR aims to shed some light on the problem and specifies how our
server should handle these requests.
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
- Adding a new image to indicate that you also need to save the strategy
after you add a constraint
- Adding a new image showing how the edit constraint section looks like
- Update a bit the text to match the new images
Added a detailed explanation into how frontend / client-side SDKs behave
with regards to fetching multiple feature flags and network
connectivity.
Content has been reviewed/approved by engineering rotation team (Simon
and Chris).
## About the changes
Refactor the main nav, with the following goals:
* Communicate the value of each section vs the format (ex:
“Understanding Unleash” vs “Topic Guides”)
* Make space for the Feature Flag tutorials section that we’re starting
to build
* Scope updates to navigation and pages that need updates based on new
URLs & organization
* Update URLs to follow the new hierarchy without breaking links (adding
redirects & editing internal links between pages as needed)
### Important files
sidebar.js
docusaurus.config.js
## Discussion points
* Redirects can't be tested out of prod, which is a bummer :/
* Some URLs have been preserved untouched while we monitor for potential
negative SEO impact of client-side redirects
* It's a large PR (sorry). Nav changes and file movements impacted lots
of files.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
### What
This PR makes the rate limit for user creation and simple login (our
password based login) configurable in the same way you can do
metricsRateLimiting.
### Worth noting
In addition this PR adds a `rate_limit{endpoint, method}` prometheus
gauge, which gets the data from the UnleashConfig.
### What
The heaviest requests we serve are the register and metrics POSTs from
our SDKs/clients.
This PR adds ratelimiting to /api/client/register, /api/client/metrics,
/api/frontend/register and /api/frontend/metrics with a default set to
6000 requests per minute (or 100 rps) for each of the endpoints.
It will be overrideable by the environment variables documented.
### Points of discussion
@kwasniew already suggested using featuretoggles with variants to
control the rate per clientId. I struggled to see if we could
dynamically update the middleware after initialisation, so this attempt
will need a restart of the pod to update the request limit.
PR contains the following:
1) New video embeds for the following docs:
- website/docs/reference/deploy/environment-import-export.mdx
- website/docs/reference/playground.mdx
- website/docs/reference/strategy-constraints.md
- website/docs/topics/a-b-testing.md
2) Improvements to the Academy course playlist embedding for the three
Academy courses. Tested the standard method of embedding video, and it
seems this works well for playlists too.
Switching to the native Docusaurus embed solves the issue with dynamic
resizing. Rather than a static embed size the video will now scale to
the browser window size.
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### 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? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Co-authored-by: Drew Gorton <dgorton@users.noreply.github.com>
Co-authored-by: Mark Fulton <128738155+markunl@users.noreply.github.com>
Adds a small troubleshooting guide for Unleash features availability.
This is not specific to features that have a visual component in the
admin UI, but that's the most common scenario.
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.
