Batch Metrics as a capability developed to support the frontend API to
handle more metrics from SDKs without overloading the DB to much. It has
been running in Unleash Cloud for months and has proven to work quite
nice.
This PR simply removes the flag to make the capability GA, also for
self-hosted users.
## About the changes
This fixes response time metrics with app names when the app just starts
and has zero which is falsy. We want to compare against undefined (which
means the snapshot is not yet ready)
## About the changes
While trying to count only features that are not archived to display the
amount of features of a project, accidentally we filtered out projects
with all features archived (they should show up in the list but with
count of features zero)
This PR takes the project status API a step further by adding the
capability of providing a date to control the selection. We are
currently making calculations based on a gliding 30 day window, updated
once a day. The initial database structure and method for updating the
UI is outlined in this PR.
## About the changes
This PR adds two new functions that is protected by CR. When used
instead of the current setVariantOnEnv and setVariantsOnEnv if the flag
UNLEASH_EXPERIMENTAL_CR_ON_VARIANTS is set, the call is blocked. This
leaves the old functions, which is used from the CR flow in place, and
adds new methods protected by CR.
Also adds e2e tests verifying that the methods will block requests if CR
is enabled for project:environment pair, as well as not block if CR is
not enabled. Tests already in place should confirm that the default
flow, without the flag enabled just works.
## About the changes
Add warnings when we detect something might be wrong with the customer
configuration, in particular with regard to variants configuration
## Rationale
Moving from variants per feature to variants per environment will allow
users to have fine-grained permissions and more control over variants on
different environments: #2254
But because this requires an additional step of copying variants to
other environments, we identified the potential risk of users forgetting
to follow this step. To keep them informed about this, we're introducing
a warning sign after a toggle is enabled when we detect that:
1. The environment is enabled without variants
2. Other enabled environments have variants
This situation would be a problem if you rely on `getVariant` method
from the SDK, because without variants you'll receive the default
variant. Probably, not what you'd expect after enabling the toggle, but
there are situations where this might be correct. Because of the latter,
we thought that adding a warning and letting the user handle the
situation was the best solution.
## UI sketches
Co-authored-by: Nuno Góis <github@nunogois.com>
## About the changes
This PR adds the ability to push variants to multiple environments
overriding the existing variants.
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2254
**Note:** This won't fail if there are variants in other environments, because the operation wouldn't be idempotent. It should have that property because setting variants to 1 or more environments once or twice should not make a difference
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- 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? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Adds support for case for IN and NOT_IN operators
<!-- 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? -->
<img width="1547" alt="Screenshot 2023-01-18 at 11 35 10"
src="https://user-images.githubusercontent.com/104830839/213136158-25c525c8-de82-423b-93d1-5ae6eb8469fa.png">
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
This PR moves the getProjectOverview method out from the project health
controller. It doesn't make sense that this method lives here anymore,
as over time it has grown into method that relays all information about
a single project. It makes more sense that this now lives on the root of
the project api. Also removes unwanted duplication of getProjectOverview
from the project-service and the project-health-service.
## About the changes
When exporting v3, for variants backward compatibility, we need to find
one featureEnvironment and fetch variants from there.
In cases where the default environment is disabled (therefore does not
get variants per environment when added), it can be still be selected
for the export process. Therefore variants don't appear in the feature
when they should be there.
An e2e test that fails with the previous implementation was added to
validate the behavior
This comes from our support ticket 404
## About the changes
Introduce a snapshot version of instanceStats inside
instance-stats-service to provide a cached state of the statistics
without compromising the DB.
### Important notes
Some rule-of-thumb applied in the PR that can be changed:
1. The snapshot refresh time
2. The threshold to report appName with the metrics
## Discussion points
1. The snapshot could be limited to just the information needed (things
like `hasOIDC` don't change until there's a restart), to optimize the memory usage
3. metrics.ts (used to expose Prometheus metrics) has a [refresh
interval of
2hs](2d16730cc2/src/lib/metrics.ts (L189-L195)),
but with this implementation, we could remove that background task and
rely on the snapshot
4. We could additionally update the snapshot every time someone queries
the DB to fetch stats (`getStats()` method), but it may increase
complexity without a significant benefit
Co-authored-by: Mateusz Kwasniewski <kwasniewski.mateusz@gmail.com>
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
## About the changes
This is a follow-up on #1953
This implementation generalizes how we fetch some standard parameters
from the query parameters or request body.
## Discussion points
Unfortunately, we have not used standard names for our APIs and one
example is our `projectId` (in some cases we just used `project`).
Ideally, we're only using one way of sending these parameters either
`projectId` or `project` (same applies to `environment` vs
`environmentId`).
If both parameters are present, due to historical reasons, we'll give
precedence to:
- `projectId` over `project`
- `environment` over `environmentId`
In the presence of both query parameters and body, we'll give precedence
to query parameters also for historical reasons.
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- 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! ❤️ -->
This PR fixes the admin feature schema by moving the `strategies`
(featureStrategySchema) from the root of `feature` object to
`feature.environment`
## 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? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
This uses log-level warning so we can turn off the log without turning
off all error logs. This could potentially be tweaked further by using
log categories in the log configuration.
Closes#2057
## About the changes
According to our docs, we only support up to 1 decimal place for
weights. This is to use integers to represent the percentages (we divide
them by 10) and supporting more decimals results in bad maths due to
floating point arithmetics.
This PRs adds Frontend and Backend validations to enforce this
restriction
Closes#2222
## Discussion points
Should we reconsider supporting more decimal places, that door remains
open, but for now we'll just adhere to our documentation because that
change would require some development.
## About the changes
When exporting features one is normally also interested in disabled
features, so they are also included in the export file, while the
variants are not. I do not see a good reason for that, so this PR
removes the check and exports the variants then as well.
I could also add an option as well, but as long as there is no good
reason for ignoring the variants I would just export them with the
features.
This PR adds tests on #2719Closes#2719
Co-authored-by: Martin Joehren <martin.joehren@esailors.de>
We have experienced side-effects where the import was unexpected and
resulted in environments thought to be removed. This had the unexpected
side-effect of also deleting API keys for some environments not part of
the import file.
This commit removes the ability of the state-service to mutate api keys
directly. There is no compelling reasons why we should remove API keys
as part of an import query.
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
To avoid showing too much data in the traffic screen, limit the number
of results to `topk`.
## Discussion points
Top 10 is a rule of thumb, but maybe we could do top 25. Until we gather
more data, I believe this should be good enough
## What
Previously when importing strategies we've used the same data type we've
used for creating strategies (the minimal, a name, an optional
description, optional parameters and an optional editable column). This
meant that exporting strategies and then importing them would reactivate
deprecated strategies. This PR changes to allow the import to preserve
all the data coming in the export file.
## Tests
Added four new tests, two new unit tests using our fake stores and two
new e2e tests. Interestingly the ones in the fake store ran green before
this change as well, probably because we just insert the parsed json
object in the fake store, whereas the real store actually converts the
object from camelCasing to the postgresql snake_casing standard.
## Discussion points:
### Mismatch between fake and real stores
This is inevitable since storing things in javascript arrays vs saving
in a real database will have some differences, but this again shows the
value of our e2e tests.
### Invariants
Should we see if we can add some invariants to our import/export so that
we can write some proptests for it? One candidate is commutativity of
import/export. On a fresh database importing and then exporting should
yield the same file that was imported provided all flags are turned on.
Candidate for Q1 improvement of import/export.
Adding stricter types to `FlagResolver` can possibly help improve our DX
- Help us prevent errors like typos, guide us to correctly add a flag
when needed, and warn us of stray checks whenever we do a clean up at a
later stage.
## About the changes
This PR improves our queries to Prometheus (instead of making multiple queries do only one) and improves the UI and the code.
The reports aggregate all HTTP methods (GET, POST, PUT, DELETE, OPTIONS, HEAD and PATCH) without distinction under the same "endpoint" (a relative path inside unleash up to a certain depth)
Co-authored-by: Nuno Góis <nuno@getunleash.ai>
## About the changes
This metric will expose an aggregated view of how many client
applications are registered in Unleash. Since applications are ephemeral
we are exposing this metric in different time windows based on when the
application was last seen.
The caveat is that we issue a database query for each new range we want
to add. Hopefully, this should not be a problem because:
a) the amount of ranges we'd expose is small and unlikely to grow
b) this is currently updated at startup time and even if we update it on
a scheduled basis the refresh rate will be rather sparse
## Sample data
This is how metrics will look like
```
# HELP client_apps_total Number of registered client apps aggregated by range by last seen
# TYPE client_apps_total gauge
client_apps_total{range="allTime"} 3
client_apps_total{range="30d"} 3
client_apps_total{range="7d"} 2
```
## About the changes
The deprecated /api/admin/features endpoint supported querying with tag
and namePrefix parameters.
This PR adds this functionality to
/api/admin/projects/<project>/features as well, allowing to replicate
queries that used to work.
Closes#2306
### Important files
src/lib/db/feature-strategy-store.ts
src/test/e2e/stores/feature-strategies-store.e2e.test.ts
## Discussion points
I'm extending our query parameters support for
/api/admin/projects/<projectId>/features endpoint. This will be
reflected in our open-api spec, so I also made an
adminFeaturesQuerySchema for this.
Also, very open for something similar to what we did for the modifyQuery
for the archived parameter, but couldn't come up with a good way to
support subselects using the query builder, it just ended up blowing the
stack. If anyone has a suggestion, I'm all ears.
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## What
We've already added the backend for this. This is the initial work for
drawing a chart for instance traffic in the frontend. It requires the environment variable `PROMETHEUS_API` set to a valid prometheus-query-language (promql) supported backend, such as Prometheus itself or Victoria Metrics. Besides, at the moment we're hiding this functionality behind the flag `UNLEASH_EXPERIMENTAL_NETWORK_VIEW` which has to be set to true
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
In this PR we remove the general SettingService cache, as it will not
work across multiple horizontal unleash instances, events are not
published across.
We also fix the CORS origin to:
- Access-Control-Allow-Origin set to "*" if no Origin is configured
- Access-Control-Allow-Origin set to "*" if any Origin is configured to
"*"
- - Access-Control-Allow-Origin set to array and have the "cors"
middleware to return an exact match on the user provided Origin.
Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
## About the changes
This connects our backend with Prometheus (or compatible) metrics
service, and exposes raw data (i.e. acting as a proxy)
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
Is protected behind a config option called `enableHeapSnapshotEnpoint`.
When API endpoint is triggered it will write a heapSnapshot to disk.
Steps to create heap snapshot:
1. Add env variable `ENABLE_HEAP_SNAPSHOT_ENPOINT=true`.
2. Call this endpoint: `/internal-backstage/heapSnapshot`
3. Download the created heapdump from the server.
The snapshot can be loaded in the chrome dev-tool to analysis.
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- 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! ❤️ -->
This PR puts the ui flags in the index.html in a meta tag. This makes
them accessible without logging in and allows us to track user signups
with invite links
## 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? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
This PR addresses some issues when working with variants after migrating
to variants per environment.
**Problem:** since PATCH
`/api/admin/projects/default/features/${featureName}/variants` does not
take into account `featureEnvironments`, when variantsPerEnvironment
gets enabled, this method will override the variants in other
environments (i.e. not doing a patch). This method has to be maintained
because of backward compatibility but it has to be adapted to deal with
variants per environment
https://linear.app/unleash/issue/2-476/when-using-patch-for-variants-without-environments-it-wipes-out
Co-authored-by: Nuno Góis <github@nunogois.com>
## What
This PR fixes some broken links we had in the application. It also adds
redirects for those links so that they should work in the future.
## Why
Because it's important to have links that work 💁
Removes feature flags for syncing sso groups and clone environment.
These features are being made generally available for all who have
access to environments and sso groups
This removes stray onlys in our tests and adds a linter rule that will
error if only is present. Also updates the test result of one of our
tests as a result of [this pull
request](https://github.com/Unleash/unleash/pull/2344)
## About the changes
With the latest changes of variants per environment, we switched to
export schema v4 without having the feature toggle enabled. This moves
the variants to `featureEnvironments` when they were previously in
`features`. The main problem is that it can create confusion as the
exported file has the same variants for each one of the environments but
after importing the file the UI will only show one set of variants
attached to the feature.
With this change, we're maintaining the previous schema until the
feature toggle is enabled.
Adds ability to favorite projects.
1. Can favorite project
2. Can unfavorite project
3. Favorite field is returned on `/api/admin/projects/default`
4. Favorite field is returned on` /api/admin/projects`
## About the changes
When adding a new migration, we might run out of memory. Migrations have
only JS files and we're running these through TS parser. Removing TS
config reference from `.eslintrc` proved to solve the issue while
running local manual tests
This still lints migration files but using JS syntax
## About the changes
We need a way to have an audit log for operations made on Api Tokens.
These changes adds three new event types, API_TOKEN_CREATED,
API_TOKEN_UPDATED, API_TOKEN_DELETED and extends api-token-service to
store these to our event store to reflect the action being taken.
* This PR adds a configurable maxAge header to the CORS middleware. This
allows the preflight request to be cached so that we can reduce the
request load on our end for the frontend clients starting to utilise the
frontend api.
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
This PR introduces a soft landing page to the last viewed project or to
the project list (if there is more than 1 project)
Changes:
- Replaced clearing of `storage` with clearing `cache` in logout.ts ::
REVERTED
- Root redirects to `projects` instead of `features`
<!-- 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? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Previously we hard deleted the users, but due to change requests and
possibly other features in future, we really want to hard-link user
table and have meaningful relationships.
But this means, when user is deleted, all linked data is also deleted.
**Workaround is to soft delete users and just clear users data and keep
the relationships alive for audit logs.**
This PR implements this feature.
patches an issue where cloning a feature would clone variants for
it's last found environment in the db. This now will clone the feature
environments correctly
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
## About the changes
This test fails randomly, example:
https://github.com/Unleash/unleash/actions/runs/3496006349/jobs/5853415518#step:5:376
It's not so frequent but I tested locally one out of 4 or 8 runs fails
because the rows returned are in the wrong order.
## Discussion points
If the order of segments is relevant, we should look into how we're
fetching them or applying a `sort()` before returning from the query.
I've validated on my machine that even if the segments are sent in
order, when pulled from the db sometimes they are processed in a
different order
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- 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! ❤️ -->
This PR implements the `all` endpoint of unleash-proxy, by adding an
experimental flag that can control the behaviour
## 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? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
Variants are now stored in each environment rather than in the feature
toggle. This enables RBAC, suggest changes, etc to also apply to
variants.
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2254
### Important files
- **src/lib/db/feature-strategy-store.ts** a complex query was moved to
a view named `features_view`
- **src/lib/services/state-service.ts** export version number increased
due to the new format
## Discussion points
We're keeping the old column as a safeguard to be able to go back
Co-authored-by: sighphyre <liquidwicked64@gmail.com>
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- 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! ❤️ -->
This PR adds (back) the permissions and eventType module exports
## 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? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
https://linear.app/unleash/issue/2-425/variants-crud-new-environment-cards-with-tables-inside-add-edit-and
Basically created parallel components for the **variants per
environments** feature, so both flows should work correctly depending on
the feature flag state. Some of the duplication means that cleanup
should be straightforward - Once we're happy with this feature it should
be enough to delete
`frontend/src/component/feature/FeatureView/FeatureVariants/FeatureVariantsList`
and do some little extra cleanup.
I noticed we had some legacy-looking code in variants, so this involved
*some* rewriting of the current variants logic. Hopefully this new code
looks nicer, more maintainable, and more importantly **doesn't break
anything**.
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2254
### Important files
Everything inside the
`frontend/src/component/feature/FeatureView/FeatureVariants/FeatureEnvironmentVariants`
folder.
fix: broken UI when importing features into environments which are not linked to the feature's project
## Related to
- PR: https://github.com/Unleash/unleash/pull/2209
- Issue: https://github.com/Unleash/unleash/issues/2186
- Issue: https://github.com/Unleash/unleash/issues/2193
## Expected behaviour:
After importing we should see:
## About the changes
**The problem:** when we import we have projects, features and
environments. Each feature belongs to a project (this is by default and
the imported file enforces that). The links between projects and
features, or projects and environments, depend on us creating those
relationships. When we add a feature to an environment we're not
validating that the project and the environment are connected. Because
of that, in some situations (like in this test), we can end up with a
project with features but no environment.
This breaks a weak constraint we had which is that all projects should
have at least one environment.
**This PR makes the following assumption when importing**: _if a feature
is added to an environment, and that environment is still not linked to
the project that feature belongs to, then the project and environments
have to be linked_. The rationale behind this is that the user couldn't
have generated this export file without the project and environment
being linked together.
<!-- 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! ❤️ -->
This PR sets up exports so that we can import in enterprise with just
"unleash-server".
This will free us to refactor unleash internals without breaking
enterprise
## 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? -->
This PR adds implements the frontend and migrations part of multiple
reviewers.
2 UI parts:
1. Configuration to add the count of required approvals
2. Handle multiple approvers in review page.
<!-- 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! ❤️ -->
Add change_request_settings table
Remove change_request_enabled column
## 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? -->
