This PR cleans up the projectListViewToggle flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10526
## 🧹 AI Flag Cleanup Summary
This change removes the `projectListViewToggle` feature flag and
hardcodes its
behavior. The feature, which allows toggling between card and list views
for
projects, is now permanently enabled.
### 🚮 Removed
- **Flag Definitions**
- Removed `projectListViewToggle` from `src/server-dev.ts`,
`src/lib/types/experimental.ts`, and
`frontend/src/interfaces/uiConfig.ts`.
- **Hooks & Conditionals**
- Removed `useUiFlag('projectListViewToggle')` calls from
`ProjectGroup.tsx`
and `ProjectList.tsx`.
- Removed conditional rendering logic based on the flag in
`ProjectGroup.tsx`
and `ProjectList.tsx`.
### 🛠 Kept
- **Project List View**
- The project list view functionality is now always available for
non-OSS
versions of Unleash.
- The `ProjectsListViewToggle` component is now always rendered when not
in an
OSS environment.
### 📝 Why
The `projectListViewToggle` feature flag was marked as completed and its
intended outcome was to be kept. The code has been updated to reflect
this by
removing the flag and making the feature a permanent part of the
application.
This simplifies the codebase by removing dead code paths and feature
flag
checks.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Deletes the legacy insights charts component (which should have been
removed with the flag earlier this week), and also removes the colors
associated with charts that we no longer have.
This PR cleans up the createFlagDialogCache flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10504
## 🧹 AI Flag Cleanup Summary
This change removes the `createFlagDialogCache` feature flag, making its
functionality permanent. The create-feature-flag dialog will now always
cache
its state in local storage.
### 🚮 Removed
- **TypeScript Definitions**
- Removed `createFlagDialogCache` from `UiFlags` in
`frontend/src/interfaces/uiConfig.ts`.
- Removed `createFlagDialogCache` from `IFlagKey` in
`src/lib/types/experimental.ts`.
- **Flag Configuration**
- Removed the `createFlagDialogCache` flag definition from
`src/lib/types/experimental.ts`.
- **Conditional Logic**
- Removed the `useUiFlag` hook and conditional logic for caching in
`frontend/src/component/project/Project/PaginatedProjectFeatureToggles/ProjectFe
atureTogglesHeader/CreateFeatureDialog.tsx`.
### 🛠 Kept
- **Feature Functionality**
- The feature of caching the create-flag dialog's form state in local
storage
is now always enabled.
### 📝 Why
The `createFlagDialogCache` feature has been successfully rolled out and
is now
considered stable. This cleanup removes the obsolete feature flag and
hardcodes
the enabled behavior, simplifying the codebase.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the lifecycleMetrics flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10505
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the crDiffView flag. These changes were automatically
generated by AI and should be reviewed carefully.
Fixes#10484🧹 AI Flag Cleanup Summary
This PR removes the crDiffView feature flag and its associated legacy
components
for displaying changes in a Change Request. The flag has been enabled
and the
new diff view is now permanent.
This involved removing the feature flag from the configuration and code,
deleting several legacy components, and updating the components that
used them
to only use the new versions.
🚮 Removed
• Feature Flag Logic
• All checks for the crDiffView flag.
• The flag definition in uiConfig.ts, experimental.ts, and
server-dev.ts.
• Legacy Components
• LegacyStrategyChange.tsx
• StrategyTooltipLink.tsx
• LegacyReleasePlanChange.tsx
• SegmentTooltipLink.tsx
• LegacySegmentChangeDetails.tsx
• LegacyArchiveFeatureChange from ArchiveFeatureChange.tsx
• LegacyDependencyChange from DependencyChange.tsx
• LegacyToggleStatusChange from ToggleStatusChange.tsx
🛠 Kept
• New Components
• The new change request diff view components (StrategyChange,
ReleasePlanChange, etc.) are now used directly.
• The UI for displaying changes in a Change Request now consistently
uses
the improved diff view.
📝 Why
The crDiffView feature flag was deemed complete and ready for permanent
implementation. The cleanup follows standard procedure to remove the
flag and
associated dead code, simplifying the codebase and making it easier to
maintain.
This change makes the improved diff view for change requests the only
available
view.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the improvedJsonDiff flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10483
## 🧹 AI Flag Cleanup Summary
This PR removes the `improvedJsonDiff` feature flag, making the enhanced
JSON
diffing component the default and only option. The now-unused legacy
diff
component and all related feature flag logic have been removed to
streamline the
codebase.
### 🚮 Removed
- **Components**
- `OldEventDiff` component was removed, along with its helper types and
constants.
- **Flag Logic**
- All conditional rendering based on the `improvedJsonDiff` flag was
removed.
- The `sort` prop from `EventDiff` was removed as it was only used by
the
legacy component.
- **Configuration**
- `improvedJsonDiff` flag definition was removed from `uiConfig.ts`,
`experimental.ts`, and `server-dev.ts`.
- **Tests**
- Mock configuration for `improvedJsonDiff` in tests was removed.
### 🛠 Kept
- **Components**
- `NewEventDiff` was renamed to `EventDiff` and is now the standard
implementation.
### 📝 Why
The `improvedJsonDiff` feature flag was marked as completed with its
outcome
being "kept". This cleanup finalizes the feature rollout by removing the
flag
and associated legacy code, simplifying the implementation and reducing
code
complexity.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the timestampsInChangeRequestTimeline flag. These
changes were automatically generated by AI and should be reviewed
carefully.
Fixes#10491
## 🧹 AI Flag Cleanup Summary
This PR removes the `timestampsInChangeRequestTimeline` feature flag.
The
feature is now permanently enabled.
⚠️ No conditional logic for this flag was found in the provided files.
The
changes are limited to removing flag definitions and configurations. The
actual
logic may reside in other parts of the codebase not included in this
operation.
### 🚮 Removed
- **Flag Definitions & Configuration**
- Removed `timestampsInChangeRequestTimeline` from `IFlagKey` type in
`src/lib/types/experimental.ts`.
- Removed `timestampsInChangeRequestTimeline` flag configuration from
`src/lib/types/experimental.ts`.
- Removed `timestampsInChangeRequestTimeline` from the `UiFlags`
interface in
`frontend/src/interfaces/uiConfig.ts`.
- Removed the flag from the experimental flags in `src/server-dev.ts`.
### 🛠 Kept
- **Feature Functionality**
- The behavior previously enabled by the
`timestampsInChangeRequestTimeline`
flag is now the default and only behavior.
### 📝 Why
The `timestampsInChangeRequestTimeline` feature flag was marked as
completed
with an intended outcome of "kept". This means the feature has been
rolled out
successfully and should be permanent. This cleanup removes the obsolete
flag and
its related configurations, simplifying the code and adhering to best
practices
for feature flag lifecycle management.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
https://linear.app/unleash/issue/2-3738/clear-unknown-flags-every-24h-instead-of-every-7d
Clears unknown flags every 24h instead of every 7d.
This ensures the list stays more relevant by removing stale entries
sooner, allowing users to focus on actively reported unknown flags.
Also includes small improvements, including a new paragraph on the
unknown flags page that better explains the concept of unknown flag
reports.
Adds an example date as a detail of the locale picker, so that the user
can see what effect their chosen locale would have on date formatting:
<img width="436" height="157" alt="image"
src="https://github.com/user-attachments/assets/d5757380-3cda-4857-99d7-bac8866d31f5"
/>
The example wraps on smaller screens:
<img width="291" height="207" alt="image"
src="https://github.com/user-attachments/assets/e3ef1678-6846-4027-b563-253195e2de99"
/>
The example date is the **date and time of the very first commit in the
Unleash repo**. By some stroke of luck, it happens to have everything
we're looking for:
- A date that is more than the 12th (to clearly differentiate between
days and months)
- A month that is less than 10 (to show whether leading zeroes are shown
or not)
- An hour that is more than 11 to show whether it's a 24-hour clock or
an AM/PM system
The date string is without a time zone offset because that means it'll
always be interpreted as local time for the user. MDN's [docs on Date
and what happens when you call it with a time
string](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_time_string_format)
state that:
> When the time zone offset is absent, date-only forms are interpreted
as a UTC time and **date-time forms are interpreted as a local time**.
I've checked this by changing my locale. With the timezone offset, the
time changes based on my timezone, but without it, it always shows as
the expected value.
Fixing the issue where modal with an active segment (for deletion) can
change which segment it's listing if a new segment that is
alphabetically earlier than the original segment
## About the changes
Rebrand SDK tokens and SDK types to make it easier to onboard and use:
**Backend SDK Token**: Intended for server-side SDKs. It can be used to
access:
- The Client Features API (/api/client/features) for fetching all flag
configurations for local evaluation.
- The Frontend API (/api/frontend) for remote evaluation.
**Frontend SDK Token**: Intended for client-side/frontend SDKs. It is
restricted and can only be used to access:
- The Frontend API (/api/frontend) for remote evaluation.
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
