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>
Adds a timestamp for each state we have time (and that isn't a state
downstream from the current state) in the CR timeline.
<img width="437" height="318" alt="image"
src="https://github.com/user-attachments/assets/a499e73f-c506-46a0-8d1a-7e4eb5ec4f7d"
/>
The timestamp respects the user's preferred locale and uses the `time`
element.
I've used the current name of the API payload's timestamps as it stands
on the enterprise main branch for now. This name is not set in any
schemas yet, so it is likely to change. Because it's not currently
exposed to any users, that will not cause any issues. Name suggestions
are welcome if you have them.
We only show timestamps for states up to and including the current
state. Timestamps for downstream states (such as "approved" if you're in
the "in review" state), will not be shown, even if they exist in the
payload. (There are some decisions to make on whether to include these
in the payload at all or not.)
There's no flags in this PR. They're not necessary If the API payload
doesn't contain the timestamp, we just don't render the timestamp, and
the timeline looks the way it always did:
<img width="447" height="399" alt="image"
src="https://github.com/user-attachments/assets/0062393a-190c-4099-bc16-29f9da82e7ea"
/>
## Bonus work
In the `ChangeRequestTimeline.tsx` file, I've made a few extra changes:
- `createTimelineItem` and `createScheduledTimelineItem` have become
normal React components (`TimelineItem` and `ScheduledTimelineItem`) and
are being called as such (in accordance with [React
recommendations](https://react.dev/reference/rules/react-calls-components-and-hooks#never-call-component-functions-directly)).
- I've updated the subtitles for schedules to also use the time element,
to improve HTML structure.
## Outstanding work
There's a few things that still need to be sorted out (primarily with
UX). Mainly about how we handle scheduled items, which already have time
information. For now, it looks like this:
<img width="426" height="394" alt="image"
src="https://github.com/user-attachments/assets/4bfc4ca2-c738-4954-9251-8d063143371e"
/>
<img width="700" height="246" alt="image"
src="https://github.com/user-attachments/assets/fe688b08-c5c8-40f8-a9d0-fe455e44665f"
/>
The console was complaining. I suspect it was because of the wrapping
fragment. So instead of doing everything within react, I switched to
using a standard case statement.
Also: because name is optional and not guaranteed to be unique, let's
use id for the key instead.
- checkbox to select 'rate' vs 'increase' - always available for now,
but does nothing for gauge. I can improve it later on
- better preview - it will show resolved query underneath
- cleaner error handling that doesn't overflow widgets
Updates a few remaining places where we check constraint operators with
the new constraint operator checks. Additionally, because there was only
one remaining place where we used the `oneOf` function, I replaced it
with a normal `includes` check and deleted the `oneOf` util. From what I
can tell, there's no need to have that utility function; it doesn't
provide much benefit over using the language built-ins 🤷🏼
Doesn't clear the value from the constraint input value popover if you
close it and then re-open. In other words, if you accidentally click
out, you don't lose your progress. Instead, the popover will open again,
with the value you had when you closed it highlighted (so that it's easy
to type over if you want to):
<img width="452" alt="image"
src="https://github.com/user-attachments/assets/d86aa00e-4956-40a8-8fea-e75be5d5425b"
/>
The reason I'm changing this now is because I noticed that the error
wasn't cleared correctly when the popover was closed. If we do it this
way instead, then that makes sense, because you can still see the value.
This is also how the single-value popover has worked forever.
From some quick testing, the single value popover still works as
expected:
<img width="562" alt="image"
src="https://github.com/user-attachments/assets/9041a922-b055-4310-ab60-93ad219981a4"
/>
As a side note: I'm adding a comment to anyone coming after as to why
focus handling on escape doesn't work correctly on the single value
button. I was about to go down a rabbit hole on that before I read my
own comment on the previous PR. So I thought I'd put that here too.
Makes it so that the constraint value input gives you an error if you
try to add one or more values that **all** exist in the set of values
already. E.g. if you have `a` and `b`, and try to add `a`, it'll tell
you that "`a` has already been added". Likewise, if you try to add
`a,b`, it'll tell you that all these values already exist. However, if
at least one of the values does not exist, then it will allow you to
submit the values (we already do deduplication before storing anyway).
The background for this is that a user was confused thinking that just
one specific value didn't get added to their constraints. As it turns
out, they'd already added the value previously, so when it didn't show
up at the end of the list, they thought it didn't work at all.
<img width="863" alt="image"
src="https://github.com/user-attachments/assets/12195e0a-04bc-4b41-bd44-432120c768a6"
/>
<img width="816" alt="image"
src="https://github.com/user-attachments/assets/433a64d7-aec0-482d-8544-574656c266ce"
/>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This PR updates how we show old/new strategy/segment names in change
requests, and also removes the name of the strategy type from the
change.
For the old/new names: instead of showing them stacked vertically, we
show them side by side (old name first, then new name).
Compare before:
<img width="967" alt="image"
src="https://github.com/user-attachments/assets/d3e36f49-4abc-4cd4-8ba9-752515740185"
/>
with after:
<img width="974" alt="image"
src="https://github.com/user-attachments/assets/d0f85264-b055-4c44-b985-f992f09d8dab"
/>
Only affects the new components (legacy CR view is untouched). If we get
negative feedback while rolling it out because the strat type name is
missing, we can always add it back.
The max width is set to `max(40vw, 1000px)`, so that if you're on a very
wide window, then it'll take up at most 40% of the horizontal space.
Once your window is smaller than 2500px, however, the sidebar will stop
shrinking and stay at 1000px (or as close to that as the window allows).
It'll keep shrinking with the window size.
This came up because in certain cases, such as if you have a release
template with a long description, the modal would just keep growing
until it took up 98% of the window width.
I have not set a min width for now. I don't think there is any need for
it, but if we find there is, we can add it back later.
Before:
After:
Adds "change:" to the beginning of all changes and does some work to
align the use of compononents and structure across them (supersedes
https://github.com/Unleash/unleash/pull/10260).
In doing so, I have also added new and legacy variants for all different
change components, because this has required some hierarchy
restructuring every now and then. A reason for doing that was adding the
correct wrapping behavior for components, such that on smaller screens,
we wouldn't entirely blow out and make the kebab menu invisible and
inaccessible.
It also makes it so that we switch to full-width change view earlier (at
breakpoint md instead of sm), because at sm, a lot of stuff got hidden
before we switched to full-width.
Most changes are trivial updates; I've called out bits of the code that
are not in comments.
Rendered, it looks like this:
<img width="1203" alt="image"
src="https://github.com/user-attachments/assets/36bed974-99da-4d8d-a881-ea9df7797210"
/>
One interesting and potentially quite useful side-effect, is that all
change types now use the exact same set of components in the same
fashion, as evidenced by this screenie where I've added outlines to the
hierarchy:
<img width="1020" alt="image"
src="https://github.com/user-attachments/assets/685fefcc-af7e-4697-b8f3-8260af1e2a84"
/>
The one difference is that components without a diff place the "more"
kebab menu one layer further inside to facilitate prettier wrapping (the
kebab menu can stay on the same line as the other text when wrapping):
<img width="238" alt="image"
src="https://github.com/user-attachments/assets/2b8d3174-06a8-4ad4-b366-cea97720deda"
/>
Removes the view diff hover links (and strategy icons) in the new views
and removes trailing colons.
In removing the hover links, I have split up the content of their files
(`StrategyTooltipLink` and `SegmentTooltipLink`) into
`Change{Segment|Strategy}Name` and `{Segment|Strategy}Diff`. I have
reverted the existing tooltip files to their state before I began
changing this and added deprecation notices. These old tooltips are only
used by the old components, so we don't need to work on them after all.
In doing this work, I've also updated the strategy change diff to handle
the new functionality (tabs instead of hover)
The removal of the trailing colons (so that it's `adding strategy
gradual rollout` instead of `adding strategy: gradual rollout` is in
preparation for the remaining changes to the header that we're
introducing with this change. The removal of these is not behind a flag,
so I've also done it in the legacy components. This feels like a very
low risk change, so it felt like more work to have to check a flag for
each of the different instances where we use it.
<img width="839" alt="image"
src="https://github.com/user-attachments/assets/b29b8073-c282-4b4b-948f-9a545082ac31"
/>
We don't want deleted strategies to have the red background color
anymore with the new change/diff view. As such, we can remove it in the
new component and add a todo to delete the css for it after it's gone.
<img width="1050" alt="image"
src="https://github.com/user-attachments/assets/083cbcac-5df9-47cd-bd78-2501c3bbf64e"
/>
