## 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
## 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.
## 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>
## 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>
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
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.
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.
## 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>
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! ❤️ -->
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? -->
