This PR cleans up the lifecycleGraphs flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10941
## 🧹 AI Flag Cleanup Summary
This change removes the `lifecycleGraphs` feature flag and makes the
associated
feature permanently available. The lifecycle graphs on the insights page
are now
enabled for all Enterprise users.
### 🚮 Removed
- **Configuration**
- `lifecycleGraphs` flag definition from `IFlagKey` and `flags` object
in
`src/lib/types/experimental.ts`.
- `lifecycleGraphs` flag from `UiFlags` in
`frontend/src/interfaces/uiConfig.ts`.
- `lifecycleGraphs: true` from `src/server-dev.ts` development config.
- **UI**
- The `useUiFlag('lifecycleGraphs')` hook call and associated
conditional
rendering logic in `PerformanceInsights.tsx`.
### 🛠 Kept
- **UI**
- The "New flags in production" and "Flags archived vs flags created"
widgets
are now always shown for Enterprise instances on the Performance
Insights page.
### 📝 Why
The `lifecycleGraphs` feature flag has been fully rolled out and is now
considered a permanent part of the application. This cleanup removes the
obsolete flag and its related conditional logic to simplify the
codebase.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Fixes bug that would only occur if the first thing you do (when there's
no url query params) on the page is to try to change the sort order or
change the number of results per page.
In those cases, the table state would be replaced with only the new
state from the sorting/page limit (and probably page).
In more specific terms: if you're on the page with no query params, then
that means that you're seeing your open change requests.
But if you tried to change the sorting, say, then the "state" and
"createdBy" filters would be cleared, and you would end up showing "all
change requests ever".
The fix is to spread the implicit table state into the new state before
updating the actual state, such that implicit filters become explicit
when that happens.
## Implicit filters?
So why do we have implicit filters? Partly aesthetic, partly because
that's how it works on github (github.com/pulls), and partly because
that makes it easier to share with coworkers. You just need to go to the
change requests page and copy the url. With no query params, they'll see
their own results instead of yours.
Makes all columns in the change requests table unsortable. The API
doesn't support sorting yet and it's not entirely clear that we want it
at the moment. As such, make it so that the column headers aren't
interactable to make it less misleading.
## About the changes
This helps to specify how long to show new in Unleash so we don't forget
to remove it when doing a release. This doesn't mean we should keep this
list forever, but this helps us to keep it clean in the UI at least.
### Tests
We did unit test the logic as follows (manually because it's not an easy
piece of code to test in the UI):
```typescript
test('ui-test', () => {
const showUntil = '7.3.0';
expect(lt('6.9.3', showUntil)).toBe(true);
expect(lt('7.2.3', showUntil)).toBe(true);
expect(lt('7.3.0', showUntil)).toBe(false);
expect(lt('7.3.1', showUntil)).toBe(false);
expect(lt('7.4.0', showUntil)).toBe(false);
expect(lt('8.0.0', showUntil)).toBe(false);
});
```
Fixes a few errors appearing on the "assign user/group" on the project
settings pages. Namely:
- spreading "key" into props in two places (option list and selected
chips)
- incorrect HTML nesting ([`li`'s only permitted parents are `ul`, `ol`,
and
`menu`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/li#technical_summary))
- missing key in the list (caused by nesting the `li`)
The renderOption type update is based on a [fix that was added in a more
recent version of
mui](https://github.com/mui/material-ui/pull/42689/files).
For some reason, the default tag rendering spreads the key in somehow,
so I've had to add a manual `renderTags` prop, and as such extracted the
`getOptionLabel` function. If you know a better way of sorting out the
fact that the `key` prop is spread into the default MUI chips, I'd be
very happy to implement that instead.
After some more consideration and reading, I don't think `aria-current`
is the right attribute here. Additionally, `aria-pressed` and
`aria-selected` are also not appropriate here. I can't find a suitable
alternative, so I'm falling back to the first rule of aria: if you don't
know what to do: don't do anything.
As such, I'm falling back to regular html data attributes.
This PR cleans up the newStrategyModal flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10911🧹 AI Flag Cleanup Summary
This change removes the newStrategyModal feature flag, making the new
"Add
strategy" modal the default and only experience for adding strategies to
a
feature.
I've removed the flag checks and the legacy code paths for the old
strategy
menu. The FeatureStrategyMenu component is now simplified to only render
the new
modal experience. I have also removed the flag from backend
configurations and
frontend interfaces.
🚮 Removed
• Feature Flag: newStrategyModal flag definition and configuration from
experimental.ts, server-dev.ts, and uiConfig.ts.
• Conditional Logic: All checks for the newStrategyModal flag in
FeatureStrategyMenu.tsx.
• Legacy Components: The old strategy menu
(LegacyFeatureStrategyMenuCards) and
related dialogs (LegacyReleasePlanReviewDialog) have been removed from
FeatureStrategyMenu.tsx.
• Unused Code: Unused state variables, functions
(openDefaultStrategyCreationModal, openReleasePlans), and imports
related to
the legacy strategy menu have been cleaned up.
🛠 Kept
• New "Add strategy" modal: The new modal for adding strategies is now
the only
implementation. Its user experience is preserved and made default.
📝 Why
The newStrategyModal feature has been completed, and the decision was to
keep
the new user experience. This cleanup removes the complexity of
maintaining two
different UI paths for adding strategies, making the code cleaner and
easier to
maintain.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Nuno Góis <github@nunogois.com>
Add an open/closed filter to the global change requests table.
To accomodate this, the PR:
- refactors the previous `ChangeRequestFilters` into its own directory
with additional files for each of the filter groups.
- updates the change request filters to work based on the table state
instead of its own external state (this was fine with only one param,
but would've gotten too complicated with two).
<img width="1108" height="442" alt="image"
src="https://github.com/user-attachments/assets/9cda0cbc-8524-45ce-b201-260e9581a346"
/>
<img width="1101" height="381" alt="image"
src="https://github.com/user-attachments/assets/ab77b17f-5449-4987-9d08-341e856cb7ac"
/>
