Adds basic table layout for the global change requests page and makes
the page accessible at `/change-requests`.
The table is based on the project-based change request table, but with a
slightly different set of columns.
Uses mock data for now.
There's still some styling to be done for the column widths and handling
narrower screens.
<img width="1386" height="671" alt="image"
src="https://github.com/user-attachments/assets/b24ed625-d3f6-4281-ba44-30744d5063f3"
/>
If the flag is disabled, we render nothing useful.
<img width="1429" height="287" alt="image"
src="https://github.com/user-attachments/assets/289b5707-4389-4c08-bf68-55d63e186ba5"
/>
closes 1-4076
This PR contains the following updates:
| Package | Change | Age | Confidence |
|---|---|---|---|
| [vite](https://vite.dev)
([source](https://redirect.github.com/vitejs/vite/tree/HEAD/packages/vite))
| [`5.4.19` ->
`5.4.20`](https://renovatebot.com/diffs/npm/vite/5.4.19/5.4.20) |
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
### GitHub Vulnerability Alerts
####
[CVE-2025-58752](https://redirect.github.com/vitejs/vite/security/advisories/GHSA-jqfw-vq24-v9c3)
### Summary
Any HTML files on the machine were served regardless of the `server.fs`
settings.
### Impact
Only apps that match the following conditions are affected:
- explicitly exposes the Vite dev server to the network (using --host or
[server.host config
option](https://vitejs.dev/config/server-options.html#server-host))
- `appType: 'spa'` (default) or `appType: 'mpa'` is used
This vulnerability also affects the preview server. The preview server
allowed HTML files not under the output directory to be served.
### Details
The
[serveStaticMiddleware](9719497ade/packages/vite/src/node/server/middlewares/static.ts (L123))
function is in charge of serving static files from the server. It
returns the
[viteServeStaticMiddleware](9719497ade/packages/vite/src/node/server/middlewares/static.ts (L136))
function which runs the needed tests and serves the page. The
viteServeStaticMiddleware function [checks if the extension of the
requested file is
".html"](9719497ade/packages/vite/src/node/server/middlewares/static.ts (L144)).
If so, it doesn't serve the page. Instead, the server will go on to the
next middlewares, in this case
[htmlFallbackMiddleware](9719497ade/packages/vite/src/node/server/middlewares/htmlFallback.ts (L14)),
and then to
[indexHtmlMiddleware](9719497ade/packages/vite/src/node/server/middlewares/indexHtml.ts (L438)).
These middlewares don't perform any test against allow or deny rules,
and they don't make sure that the accessed file is in the root directory
of the server. They just find the file and send back its contents to the
client.
### PoC
Execute the following shell commands:
```
npm create vite@latest
cd vite-project/
echo "secret" > /tmp/secret.html
npm install
npm run dev
```
Then, in a different shell, run the following command:
`curl -v --path-as-is
'http://localhost:5173/../../../../../../../../../../../tmp/secret.html'`
The contents of /tmp/secret.html will be returned.
This will also work for HTML files that are in the root directory of the
project, but are in the deny list (or not in the allow list). Test that
by stopping the running server (CTRL+C), and running the following
commands in the server's shell:
```
echo 'import path from "node:path"; import { defineConfig } from "vite"; export default defineConfig({server: {fs: {deny: [path.resolve(__dirname, "secret_files/*")]}}})' > [vite.config.js](http://vite.config.js)
mkdir secret_files
echo "secret txt" > secret_files/secret.txt
echo "secret html" > secret_files/secret.html
npm run dev
```
Then, in a different shell, run the following command:
`curl -v --path-as-is 'http://localhost:5173/secret_files/secret.txt'`
You will receive a 403 HTTP Response, because everything in the
secret_files directory is denied.
Now in the same shell run the following command:
`curl -v --path-as-is 'http://localhost:5173/secret_files/secret.html'`
You will receive the contents of secret_files/secret.html.
####
[CVE-2025-58751](https://redirect.github.com/vitejs/vite/security/advisories/GHSA-g4jq-h2w9-997c)
### Summary
Files starting with the same name with the public directory were served
bypassing the `server.fs` settings.
### Impact
Only apps that match the following conditions are affected:
- explicitly exposes the Vite dev server to the network (using --host or
[`server.host` config
option](https://vitejs.dev/config/server-options.html#server-host))
- uses [the public directory
feature](https://vite.dev/guide/assets.html#the-public-directory)
(enabled by default)
- a symlink exists in the public directory
### Details
The
[servePublicMiddleware](9719497ade/packages/vite/src/node/server/middlewares/static.ts (L79))
function is in charge of serving public files from the server. It
returns the
[viteServePublicMiddleware](9719497ade/packages/vite/src/node/server/middlewares/static.ts (L106))
function which runs the needed tests and serves the page. The
viteServePublicMiddleware function [checks if the publicFiles variable
is
defined](9719497ade/packages/vite/src/node/server/middlewares/static.ts (L111)),
and then uses it to determine if the requested page is public. In the
case that the publicFiles is undefined, the code will treat the
requested page as a public page, and go on with the serving function.
[publicFiles may be undefined if there is a symbolic link anywhere
inside the public
directory](9719497ade/packages/vite/src/node/publicDir.ts (L21)).
In that case, every requested page will be passed to the public serving
function. The serving function is based on the
[sirv](https://redirect.github.com/lukeed/sirv) library. Vite patches
the library to add the possibility to test loading access to pages, but
when the public page middleware [disables this
functionality](9719497ade/packages/vite/src/node/server/middlewares/static.ts (L89))
since public pages are meant to be available always, regardless of
whether they are in the allow or deny list.
In the case of public pages, the serving function is [provided with the
path to the public
directory](9719497ade/packages/vite/src/node/server/middlewares/static.ts (L85))
as a root directory. The code of the sirv library [uses the join
function to get the full path to the requested
file](d061616827/packages/sirv/index.mjs (L42)).
For example, if the public directory is "/www/public", and the requested
file is "myfile", the code will join them to the string
"/www/public/myfile". The code will then pass this string to the
normalize function. Afterwards, the code will [use the string's
startsWith
function](d061616827/packages/sirv/index.mjs (L43))
to determine whether the created path is within the given directory or
not. Only if it is, it will be served.
Since [sirv trims the trailing slash of the public
directory](d061616827/packages/sirv/index.mjs (L119)),
the string's startsWith function may return true even if the created
path is not within the public directory. For example, if the server's
root is at "/www", and the public directory is at "/www/p", if the
created path will be "/www/private.txt", the startsWith function will
still return true, because the string "/www/private.txt" starts with
"/www/p". To achieve this, the attacker will use ".." to ask for the
file "../private.txt". The code will then join it to the "/www/p"
string, and will receive "/www/p/../private.txt". Then, the normalize
function will return "/www/private.txt", which will then be passed to
the startsWith function, which will return true, and the processing of
the page will continue without checking the deny list (since this is the
public directory middleware which doesn't check that).
### PoC
Execute the following shell commands:
```
npm create vite@latest
cd vite-project/
mkdir p
cd p
ln -s a b
cd ..
echo 'import path from "node:path"; import { defineConfig } from "vite"; export default defineConfig({publicDir: path.resolve(__dirname, "p/"), server: {fs: {deny: [path.resolve(__dirname, "private.txt")]}}})' > vite.config.js
echo "secret" > private.txt
npm install
npm run dev
```
Then, in a different shell, run the following command:
`curl -v --path-as-is 'http://localhost:5173/private.txt'`
You will receive a 403 HTTP Response, because private.txt is denied.
Now in the same shell run the following command:
`curl -v --path-as-is 'http://localhost:5173/../private.txt'`
You will receive the contents of private.txt.
### Related links
-
f0113f3f82
---
### Release Notes
<details>
<summary>vitejs/vite (vite)</summary>
###
[`v5.4.20`](https://redirect.github.com/vitejs/vite/compare/v5.4.19...v5.4.20)
[Compare
Source](https://redirect.github.com/vitejs/vite/compare/v5.4.19...v5.4.20)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "" in timezone Europe/Madrid,
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about these
updates again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/Unleash/unleash).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS45Ny4xMCIsInVwZGF0ZWRJblZlciI6IjQxLjk3LjEwIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR cleans up the addConfiguration flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10627
## 🧹 AI Flag Cleanup Summary
This change removes the `addConfiguration` feature flag. The feature was
discarded, so this cleanup reverts the UI to its state before the
`addConfiguration` flag was introduced. The primary change is in the
strategy
menu, where the single "Add configuration" button is removed and the
original
"Use template," "Add strategy," and "More" buttons are restored.
### 🚮 Removed
- **Flag Definitions**
- `addConfiguration` flag from `experimental.ts` on the backend.
- `addConfiguration` flag from `uiConfig.ts` on the frontend.
- `addConfiguration: true` from the `server-dev.ts` config.
- **UI Components & Logic**
- The conditional rendering in `FeatureStrategyMenu.tsx` that showed an
"Add
configuration" button.
- The `useUiFlag('addConfiguration')` hook call and its import from
`FeatureStrategyMenu.tsx`.
### 🛠 Kept
- **UI Components & Logic**
- The original set of buttons in `FeatureStrategyMenu.tsx`: "Use
template",
"Add strategy", and a "More strategies" icon button. This was the code
path for
when the flag was disabled.
### 📝 Why
The `addConfiguration` feature flag was marked as completed with the
outcome
"discarded". This cleanup removes the flag and all related code,
preserving only
the intended code path, which is the UI behavior from before the flag
was
introduced.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Nuno Góis <github@nunogois.com>
The previous implementation had a small bug where it would show "not
enough data" even if the graph was loading. This commit fixes that.
While working, I thought that maybe we should keep the current data
while we're fetching new data instead of adding a cover, but all the
other graphs use a cover when loading, so I've not made any changes to
that effect.
Uses the same custom highlighter that we've used for the other analytics
charts, but customizes it for the archive : creation ratio chart. Also
removes the color change on hover from the bars.
Because this plugin (or a version of it) is also used in the network
traffic graphs, I've consolidated all the uses into a more configurable
one (because I was mistakenly working in the wrong file).
Before:
<img width="596" height="392" alt="image"
src="https://github.com/user-attachments/assets/d4270a6d-b1c6-47ff-8e98-424d0e7fe089"
/>
After:
<img width="1141" height="476" alt="image"
src="https://github.com/user-attachments/assets/aa10aa87-e111-4a75-8dce-4a2fec7af8ad"
/>
This PR cleans up the reportUnknownFlags flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10595
## 🧹 AI Flag Cleanup Summary
This change removes the `reportUnknownFlags` feature flag and makes its
functionality a permanent part of the application. The "Unknown flags"
feature
is now always enabled.
### 🚮 Removed
- **Flag Definitions**
- Removed `reportUnknownFlags` from `IFlagKey` and `UiFlags` types.
- Removed `reportUnknownFlags` from the experimental flags configuration
in `src/lib/types/experimental.ts`.
- Removed the flag from development and test configurations
(`src/server-dev.ts`, `unknown-flags.e2e.test.ts`).
- **Conditional Logic**
- Removed conditional checks for `reportUnknownFlags` in backend
services
(`UnknownFlagsService`, `ClientMetricsServiceV2`) and API controllers
(`UnknownFlagsController`).
- Removed `useUiFlag('reportUnknownFlags')` and related conditional
rendering from frontend components (`UnknownFlagsTable`,
`FeatureToggleListTable`). The UI elements are now always visible.
- Modified the `useUnknownFlags` hook to always fetch data.
### 🛠 Kept
- **Core Functionality**
- The feature to report and display unknown flags is now always active.
- The "Unknown flags" link is now permanently visible on the feature
flags
overview page.
- Backend logic for processing and storing unknown flags is now always
executed.
### 📝 Why
The `reportUnknownFlags` feature flag was marked as completed with the
feature
being kept. This cleanup removes the flag and its associated conditional
logic,
simplifying the code and making the unknown flags reporting a permanent
feature.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Nuno Góis <github@nunogois.com>
Adds date localization to the charts on the analytics page. In doing so,
I have extracted the default locales that we allow the user to set into
constants, so that we can reference it from other places. I have also
sorted the list and added my personal favorite format (ja) to it.
Because we have multiple charts on the analytics page, it felt weird
that only one chart should follow your preferred format. It also aligns
the existing charts' tooltip date format with the new one (`P` instead
of `PPP`).
In short: previously, the charts would show you only your system locale
(I think), which for me defaults to en-US, regardless of what setting
you'd set in your profile. Now we respect your setting as long as it's
one of the default ones.
Before (date formatting is en-US):
<img width="1444" height="1658" alt="image"
src="https://github.com/user-attachments/assets/99a893c7-efb6-4e55-b47c-9df66bf97636"
/>
After (date formatting is sv-SE):
<img width="1383" height="1653" alt="image"
src="https://github.com/user-attachments/assets/d408afd9-a8a7-46f3-8c13-9f7fde608cc4"
/>
Makes it easier to understand what piece of data you're looking at. The
raw date isn't available directly, but we have the formatted version for
the tooltip, so we'll display that.
This PR changes the format to be more in line with the UX sketches (just
numbers and separators instead of words). In theory, it should also be
possible to [adjust the
locale](https://www.npmjs.com/package/chartjs-adapter-date-fns#locale-support-via-scale-options)
(in this case, it should be to the user's chosen locale), but I can't
seem to make that option work. I don't want to spend more time on that
right now, unless we get feedback on it. However, _yes_ the format is
american, and _yes_, that puts months ahead of days. However, you also
have the date in longer form on the x axis, so I think you'll be able to
work it out.
Before:
<img width="279" height="139" alt="image"
src="https://github.com/user-attachments/assets/5c71e708-9d9f-412a-acbb-7d28e5071d5a"
/>
After:
<img width="246" height="154" alt="image"
src="https://github.com/user-attachments/assets/13a4f5b3-281b-4003-8aae-a248578fead8"
/>
The tooltip should show you the ratio of the group and the numbers for
both archived and created.
The tooltip's position is averaged between all the bars in the group.
<img width="335" height="262" alt="image"
src="https://github.com/user-attachments/assets/d62a4bdc-ba07-4eea-8cbf-6e42793804b2"
/>
This still throws the same errors as before. Not sure exactly what's
going on with the custom tooltip, but I'll investigate it in a
follow-up.
Closes 1-4017.
## About the changes
In the previous fix: https://github.com/Unleash/unleash/pull/10543, we
made sure client token types were displayed in the UI. Here, we're also
making sure that the Backend token types are displayed as well.
1. A test validates that if a backend token exists in the db it will be
returned in the API response.
2. The UI has been adapted to also consider backend token types
This PR cleans up the releasePlans flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10536
## 🧹 AI Flag Cleanup Summary
The `releasePlans` feature flag has been removed, making the feature
permanently
available for Enterprise customers. All conditional logic and checks
related to
this flag have been removed from the codebase.
This change ensures that Release Plans are an integral part of the
Unleash
Enterprise offering.
### 🚮 Removed
- **Flag Definitions**
- `releasePlans` flag from `experimental.ts` in the backend.
- `releasePlans` flag from `uiConfig.ts` in the frontend.
- `releasePlans` flag from `server-dev.ts` development config.
- **Conditional Logic**
- Removed checks for `releasePlansEnabled` in components and hooks,
including
`ReleaseManagement.tsx`, `FeatureStrategyMenu.tsx`, and
`NewInUnleash.tsx`.
- Removed `useUiFlag('releasePlans')` calls from all frontend files.
- Removed the `flag: 'releasePlans'` property from route definitions in
`routes.ts`.
### 🛠 Kept
- **Feature Functionality**
- All UI and logic related to Release Plans and Release Templates are
now
unconditionally enabled for Enterprise users.
### 📝 Why
The `releasePlans` feature has been successfully rolled out and is now a
stable
part of the product. This cleanup removes the artık feature flag to
simplify the
codebase and reduce complexity.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Nuno Góis <github@nunogois.com>
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.
