1
0
mirror of https://github.com/Unleash/unleash.git synced 2025-01-25 00:07:47 +01:00
Commit Graph

2573 Commits

Author SHA1 Message Date
Jaanus Sellin
a257ca4474
feat: deleted feature names should come from event (#8978)
This is still raw and experimental.
We started to pull deleted features from event payload.
Now we put full query towards read model.

Co-Author:  @FredrikOseberg
2024-12-13 14:54:15 +02:00
Fredrik Strand Oseberg
b2cf0e4e6b
Feat/refactor polling (#8976)
This PR refactors the method that listens on revision changes:
- Now supports all environments
- Removed unnecessary populate cache method

# Discussion point

In the listen method, should we implement logic to look into which
environments the events touched? By doing this we would:
- Reduce cache size
- Save some memory/CPU if the environment is not initialized in the
cache, because we could skip the DB calls.
2024-12-13 11:25:37 +02:00
Jaanus Sellin
63d2359dec
feat: new read model for client feature toggle cache (#8975)
This is based on the exising client feature toggle store, but some
alterations.

1. We support all of the querying it did before.
2. Added support to filter by **featureNames**
3. Simplified logic, so we do not have admin API logic
- no return of tags
- no return of last seen
- no return of favorites
- no playground logic


Next PR will try to include the revision ID.
2024-12-13 10:23:46 +02:00
Fredrik Strand Oseberg
8eb84e9645
fix: initialize cache when we get the first request (#8971)
This PR changes the caching functionality so that we initialize the
cache when we receive the first request instead of frontloading the
caches.
2024-12-13 08:39:40 +01:00
Tymoteusz Czech
67864e7008
migration: add permissions for instance maintenance (#8885)
after #8875
2024-12-12 16:53:46 +01:00
Jaanus Sellin
c0925ea75c
fix: do not initialize cache when flag is off (#8969)
This feature is still in early alpha. We do not want to populate any
cache on startup. We might not want to do it ever.
2024-12-12 15:06:33 +02:00
Jaanus Sellin
59bdfcd84b
feat: first revision of delta api (#8967)
This is not changing existing logic.
We are creating a new endpoint, which is guarded behind a flag.

---------

Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
Co-authored-by: FredrikOseberg <fredrik.no@gmail.com>
2024-12-12 14:18:11 +02:00
Mateusz Kwasniewski
fe8308da1f
feat: productivity email action text (#8966) 2024-12-12 12:00:08 +01:00
Fredrik Strand Oseberg
7c646bc523
Chore/increase client api test coverage (#8950)
Added more tests around specific plans. Also added snapshot as per our
conversation @gastonfournier, but I'm unsure how much value it will give
because it seems that the tests should already catch this using
respondWithValidation and the OpenAPI schema. The problem here is that
empty array is a valid state, so there were no reason for the schema to
break the tests.
2024-12-12 11:42:18 +01:00
Mateusz Kwasniewski
37a3ec9599
fix: productivity report small screens (#8963) 2024-12-12 09:21:55 +01:00
Jaanus Sellin
17d3b5c2fb
fix: make project ui query optimized (#8961)
From 13 seconds to 0.1 seconds.

1. Joining 1 million events to projects/features is slow. **Solved by
using CTE.**
2. Running grouping on 1 million rows is slow. **Solved by adding
index.**
2024-12-12 08:41:10 +02:00
Mateusz Kwasniewski
a1f147dfef
fix: move productivity report to features dir (#8960) 2024-12-11 12:06:50 +01:00
Mateusz Kwasniewski
48b21591f6
feat: productivity report trends visualization (#8956) 2024-12-11 11:19:08 +01:00
Melinda Fekete
311df82d37
Strategy docs updates (#8711)
- New navigation for Unleash Concepts
- Updated and restructured activation strategies and related concepts
2024-12-11 10:38:39 +01:00
gitar-bot[bot]
8c189cabd2
[Gitar] Cleaning up stale flag: purchaseAdditionalEnvironments with value false (#8955)
[![Gitar](https://raw.githubusercontent.com/gitarcode/.github/main/assets/gitar-banner.svg)](https://gitar.ai)
This automated PR permanently removes the
`purchaseAdditionalEnvironments` feature flag.
  
  ---
This automated PR was generated by [Gitar](https://gitar.ai). View
[docs](https://gitar.ai/docs).

---------

Co-authored-by: Gitar <noreply@gitar.ai>
Co-authored-by: sjaanus <sellinjaanus@gmail.com>
2024-12-11 10:11:23 +02:00
Tymoteusz Czech
5cc0e589e8
feat(cjux-278): maintenance root roles (#8875)
Custom root roles for changing maintenance mode state and banners.

Internal ticket: CJUX-278
2024-12-10 15:22:46 +01:00
Mateusz Kwasniewski
9de96c8004
feat: OIDC redirect flag (#8944) 2024-12-10 09:07:00 +01:00
Mateusz Kwasniewski
23bdf0356a
feat: health rating color in email (#8943) 2024-12-09 15:44:16 +01:00
Mateusz Kwasniewski
4274bd6635
chore: view more insights color update (#8938) 2024-12-09 13:54:12 +01:00
Tymoteusz Czech
e8179d4dd2
feat(productivity-report): additional email headers test (#8540)
Test ability to add custom header to non-transactional email.
2024-12-09 11:33:25 +00:00
Mateusz Kwasniewski
d40b0795f9
feat: productivity report cta (#8936) 2024-12-09 12:32:50 +01:00
Mateusz Kwasniewski
c81d45b52c
chore: default metrics storage days updated (#8931) 2024-12-06 13:04:56 +01:00
Gastón Fournier
04eaf8d5bd
feat: add variant etag (#8922)
## About the changes
This adds a variant that allows us to control client refreshes in case
of need.
2024-12-05 15:13:11 +01:00
Nuno Góis
263aad4248
chore: streaming spike (#8907)
We need this PR to correctly set up CORS for streaming-related endpoints
in our spike and add the flag to our types.

---------

Co-authored-by: kwasniew <kwasniewski.mateusz@gmail.com>
2024-12-03 12:15:09 +00:00
Nuno Góis
c6668b411b
chore: improve release plan events and add them to event timeline (#8895)
https://linear.app/unleash/issue/2-3043/improve-release-plan-events-and-add-them-to-the-event-timeline

Improves release plan events and adds them to the event timeline.

This will break the events in Enterprise but that's okay, we can follow
up with the Enterprise PR to fix them.


![image](https://github.com/user-attachments/assets/862818a5-d9bf-4006-beca-786fd6265759)
2024-12-02 12:35:48 +00:00
Thomas Heartman
f833cf58eb
1-3060: remove features export import flag (#8890)
This PR removes all references to the `featuresExportImport` flag.

The flag was introduced in [PR
#3411](https://github.com/Unleash/unleash/pull/3411) on March 29th 2023,
and the flag was archived on April 3rd. The flag has always defaulted to
true.

We've looked at the project that introduced the flag and have spoken to CS about it: we can find no reason to keep the flag around. So well remove it now.
2024-12-02 09:26:06 +00:00
Nuno Góis
c9110224a5
chore: filter out milestone strategies in features_view (#8883)
https://linear.app/unleash/issue/2-3033/filter-out-release-plan-milestone-strategies-from-admin-feature

Filters out milestone strategies from our `features_view`.

This felt like the most elegant way to address this, since it seems we
only rely on this view to fetch the feature strategies in the admin UI.


### No more milestone strategies showing up on our UI when we have a
running milestone


![image](https://github.com/user-attachments/assets/02bac5a5-7ddb-4bde-b487-8b6bca0923b5)

### However they're still part of the client features response

```json
{
	"name": "r-plan",
	"type": "release",
	"enabled": false,
	"project": "default",
	"stale": false,
	"strategies": [
		{
			"name": "flexibleRollout",
			"constraints": [
				{
					"values": [
						"Portugal"
					],
					"inverted": false,
					"operator": "IN",
					"contextName": "country",
					"caseInsensitive": false
				},
				{
					"values": [
						"Portugal",
						"Norway"
					],
					"inverted": false,
					"operator": "IN",
					"contextName": "country",
					"caseInsensitive": false
				}
			],
			"parameters": {
				"groupId": "newOverview",
				"rollout": "100",
				"stickiness": "default"
			},
			"variants": [
				{
					"name": "A",
					"weight": 500,
					"stickiness": "default",
					"weightType": "variable"
				},
				{
					"name": "B",
					"weight": 500,
					"stickiness": "default",
					"weightType": "variable"
				}
			]
		},
		{
			"name": "flexibleRollout",
			"constraints": [],
			"parameters": {
				"groupId": "much_feature",
				"rollout": "25",
				"stickiness": "default"
			},
			"variants": []
		},
		{
			"name": "flexibleRollout",
			"constraints": [],
			"parameters": {
				"groupId": "r-plan",
				"rollout": "100",
				"stickiness": "default"
			},
			"variants": []
		}
	],
	"variants": [],
	"description": null,
	"impressionData": false
},
```
2024-12-02 08:17:17 +00:00
Jaanus Sellin
3c01813826
Revert "task: enabled in OSS." (#8892)
Reverts Unleash/unleash#8856
2024-11-29 13:42:10 +02:00
Christopher Kolstad
663b169c46
task: enabled in OSS. (#8856)
Hardcode project and environment names to filter by when OSS
2024-11-29 09:43:43 +01:00
sjaanus
0bee07ddec
chore: update texts 2024-11-28 13:48:07 +02:00
Mateusz Kwasniewski
61cb218d4d
fix: stop changing null to empty string when reading empty title (#8878) 2024-11-28 12:16:45 +01:00
David Leek
db02918a35
chore: make milestone_strategies.title nullable (#8864) 2024-11-27 09:16:24 +01:00
Jaanus Sellin
7906bfb177
chore: rename toggle to flag (#8854) 2024-11-26 09:57:43 +02:00
weekwith.me
d75c63b6e8
feat: Add PROJECT_ARCHIVED event to send message to Slack (#8848)
<!-- 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. -->

### Summary

- Add `PROJECT_ARCHIVED` event on `EVENT_MAP` to use
- Add a test case for `PROJECT_ARCHIVED` event formatting 
- Add `PROJECT_ARCHIVED` event when users choose which events they send
to Slack
- Fix Slack integration document by adding `PROJECT_ARCHIVED`

### Example

The example message looks like the image below. I covered my email with
a black rectangle to protect my privacy 😄
The link refers `/projects-archive` to see archived projects.

<img width="529" alt="Slack message example"
src="https://github.com/user-attachments/assets/938c639f-f04a-49af-9b4a-4632cdea9ca7">

## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->

I considered the reason why Unleash didn't implement to send
`PROJECT_ARCHIVED` message to Slack integration.

One thing I assumed that it is impossible to create a new project with
open source codes, which means it is only enabled in the enterprise
plan. However,
[document](https://docs.getunleash.io/reference/integrations/slack-app#events)
explains that users can send `PROJECT_CREATED` and `PROJECT_DELETED`
events to Slack, which are also available only in the enterprise plan,
hence it means we need to embrace all worthwhile events.

I think it is reasonable to add `PROJECT_ARCHIVED` event to Slack
integration because users, especially operators, need to track them
through Slack by separating steps, `_CREATED`, `_ARCHIVED`, and
`_DELETED`.
2024-11-25 14:33:50 +00:00
Christopher Kolstad
0f76a8a5a6
task: added unique index for release plan templates (#8846)
We want to prevent our users from defining multiple templates with the
same name. So this adds a unique index on the name column when
discriminator is template.
2024-11-25 11:25:55 +01:00
gitar-bot[bot]
9b4e646a98
[Gitar] Cleaning up stale flag: onboardingUI with value true (#8832)
[![Gitar](https://raw.githubusercontent.com/gitarcode/.github/main/assets/gitar-banner.svg)](https://gitar.ai)
  This automated PR permanently enables the `onboardingUI` feature flag.
  
  ---
This automated PR was generated by [Gitar](https://gitar.ai). View
[docs](https://gitar.ai/docs).

---------

Co-authored-by: Gitar <noreply@gitar.ai>
2024-11-22 11:55:24 +02:00
gitar-bot[bot]
6844984610
[Gitar] Cleaning up stale flag: trackLifecycleMetrics with value false (#8833)
[![Gitar](https://raw.githubusercontent.com/gitarcode/.github/main/assets/gitar-banner.svg)](https://gitar.ai)
This automated PR permanently removes the `trackLifecycleMetrics`
feature flag.
  
  ---
This automated PR was generated by [Gitar](https://gitar.ai). View
[docs](https://gitar.ai/docs).

Co-authored-by: Gitar <noreply@gitar.ai>
2024-11-22 11:54:28 +02:00
Thomas Heartman
5d553d0c7b
chore: allow openapi "date" format of strings (#8837)
This change opens up the possibility of using the "date" format for
strings in our OpenAPI spec. According to the official docs, [`date` is
a built-in string
format](https://swagger.io/docs/specification/v3_0/data-models/data-types/#string-formats).
2024-11-22 10:18:39 +01:00
Mateusz Kwasniewski
5c7f4d5fc1
feat: backfill archived features lifecycle (#8824) 2024-11-21 14:41:20 +01:00
Jaanus Sellin
c18952f374
feat: licensed users ui rework (#8809)
1. Moved link creation bottom next to licensed users view
2. Created licensed users component
3. Added flag

OSS:

![image](https://github.com/user-attachments/assets/cfb2b971-3861-4093-91a5-f3118b906029)
All others

![image](https://github.com/user-attachments/assets/e8cf712f-7e66-44f6-9965-1bb785e4f3fc)
2024-11-21 11:46:40 +02:00
Thomas Heartman
6d75ad73d4
fix: count lifecycle more accurately (#8816)
This PR fixes three things that were wrong with the lifecycle summary
count query:

1. When counting the number of flags in each stage, it does not take
into account whether a flag has moved out of that stage. So if you have
a flag that's gone through initial -> pre-live -> live, it'll be counted
for each one of those steps, not just the last one.

2. Some flags that have been archived don't have the corresponding
archived state row in the db. This causes them to count towards their
other recorded lifecycle stages, even when they shouldn't. This is
related to the previous one, but slightly different. Cross-reference the
features table's archived_at to make sure it hasn't been archived

3. The archived number should probably be all flags ever archived in the
project, regardless of whether they were archived before or after
feature lifecycles. So we should check the feature table's archived_at
flag for the count there instead
2024-11-21 08:12:53 +00:00
David Leek
4db1b5df03
chore: disable flagOVerviewRedesign on OSS (#8808) 2024-11-20 14:08:04 +01:00
Thomas Heartman
a59a031362
chore: minor cleanup of project health and status (#8806)
This PR:
- conditionally deprecates the project health report endpoint. We only
use this for technical debt dashboard that we're removing. Now it's
deprecated once you turn the simplifiy flag on.
- extracts the calculate project health function into the project health
functions file in the appropriate domain folder. That same function is
now shared by the project health service and the project status service.

For the last point, it's a little outside of how we normally do things,
because it takes its stores as arguments, but it slots in well in that
file. An option would be to make a project health read model and then
wire that up in a couple places. It's more code, but probably closer to
how we do things in general. That said, I wanted to suggest this because
it's quick and easy (why do much work when little work do trick?).
2024-11-20 13:59:44 +01:00
Thomas Heartman
04b2b488f6
chore(1-3133): change avg health to current health in project status (#8803)
This PR updates the project status service (and schemas and UI) to use
the project's current health instead of the 4-week average.

I nabbed the `calculateHealthRating` from
`src/lib/services/project-health-service.ts` instead of relying on the
service itself, because that service relies on the project service,
which relies on pretty much everything in the entire system.

However, I think we can split the health service into a service that
*does* need the project service (which is used for 1 of 3 methods) and a
service (or read model) that doesn't. We could then rely on the second
one for this service without too much overhead. Or we could extract the
`calculateHealthRating` into a shared function that takes its stores as
arguments. ... but I suggest doing that in a follow-up PR.

Because the calculation has been tested other places (especially if we
rely on a service / shared function for it), I've simplified the tests
to just verify that it's present.

I've changed the schema's `averageHealth` into an object in case we want
to include average health etc. in the future, but this is up for debate.
2024-11-20 11:41:45 +01:00
Thomas Heartman
20749cf771
1-3121: fix wrong counting for unhealthy flags (#8772)
This PR fixes the counting of unhealthy flags for the project status
page. The issue was that we were looking for `archived = false`, but we
don't set that flag in the db anymore. Instead, we set the `archived_at`
date, which should be null if the flag is unarchived.
2024-11-20 10:16:53 +01:00
Mateusz Kwasniewski
ec44c5b5e4
chore: remove personal dashboard UI flag (#8795) 2024-11-20 09:24:08 +01:00
Jaanus Sellin
4234020b8d
feat: backfill licensed users (#8791)
**This migration introduces a query that calculates the licensed user
counts and inserts them into the licensed_users table.**

**The logic ensures that:**

1. All users created up to a specific date are included as active users
until they are explicitly deleted.
2. Deleted users are excluded after their deletion date, except when
their deletion date falls within the last 30 days or before their
creation date.
3. The migration avoids duplicating data by ensuring records are only
inserted if they don’t already exist in the licensed_users table.


**Logic Breakdown:**

**Identify User Events (user_events):** Extracts email addresses from
user-related events (user-created and user-deleted) and tracks the type
and timestamp of the event. This step ensures the ability to
differentiate between user creation and deletion activities.
**Generate a Date Range (dates):** Creates a continuous range of dates
spanning from the earliest recorded event up to the current date. This
ensures we analyze every date, even those without events.
**Determine Active Users (active_emails):** Links dates with user events
to calculate the status of each email address (active or deleted) on a
given day. This step handles:

- The user's creation date.
- The user's deletion date (if applicable).

**Calculate Daily Active User Counts (result):** 
For each date, counts the distinct email addresses that are active based
on the conditions:

- The user has no deletion date.
- The user's deletion date is within the last 30 days relative to the
current date.
- The user's creation date is before the deletion date.
2024-11-20 09:10:07 +02:00
Thomas Heartman
b23dd940af
feat: add potentially stale filter to flags filter (#8798)
This PR adds the option to select potentially stale flags from the UI.

It also updates the name we use for parsing from the API: instead of
`potentiallyStale` we use `potentially-stale`. This follows the
precedent set by "kill switch" (which we send as 'kill-switch'), the
only other multi-word option that I could find in our filters.
2024-11-19 16:37:32 +02:00
Thomas Heartman
8da201aed8
feat: add potentiallyStale filter (#8784)
This PR adds support for the `potentiallyStale` value in the feature
search API. The value is added as a third option for `state` (in
addition to `stale` and `active`). Potentially stale is a subset of
active flags, so stale flags are never considered potentially stale,
even if they have the flag set in the db.

Because potentially stale is a separate column in the db, this
complicates the query a bit. As such, I've created a specialized
handling function in the feature search store: if the query doesn't
include `potentiallyStale`, handle it as we did before (the mapping has
just been moved). If the query *does* contain potentially stale, though,
the handling is quite a bit more involved because we need to check
multiple different columns against each other.

In essence, it's based on this logic:

when you’re searching for potentially stale flags, you should only get flags that are active and marked as potentially stale. You should not get stale flags.

This can cause some confusion, because in the db, we don’t clear the potentially stale status when we mark a flag as stale, so we can get flags that are both stale and potentially stale.

However, as a user, if you’re looking for potentially stale flags, I’d be surprised to also get (only some) stale flags, because if a flag is stale, it’s definitely stale, not potentially stale.

This leads us to these six different outcomes we need to handle when your search includes potentially stale and stale or active:

1. You filter for “potentially stale” flags only. The API will give you only flags that are active and marked as potentially stale. You will not get stale flags.
2. You filter only for flags that are not potentially stale. You will get all flags that are active and not potentially stale and all stale flags.
3. You search for “is any of stale, potentially stale”. This is our “unhealthy flags” metric. You get all stale flags and all flags that are active and potentially stale
4. You search for “is none of stale, potentially stale”: This gives you all flags that are active and not potentially stale. Healthy flags, if you will.
5. “is any of active, potentially stale”: you get all active flags. Because we treat potentially stale as a subset of active, this is the same as “is active”
6. “is none of active, potentially stale”: you get all stale flags. As in the previous point, this is the same as “is not active”
2024-11-19 14:53:01 +01:00
Thomas Heartman
82e752be45
1-3131: db migration to make potentially stale non-nullable (#8796)
This change adds a db migration to make the potentially_stale column
non-nullable. It'll set any NULL values to `false`.

In the down-migration, make the column nullable again.
2024-11-19 12:27:22 +01:00