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"
/>
This PR cleans up the etagByEnv flag. These changes were automatically
generated by AI and should be reviewed carefully.
Fixes#10556
## 🧹 AI Flag Cleanup Summary
This change removes the `etagByEnv` feature flag and makes its
functionality
permanent. This modifies the ETag generation for client API requests to
be
environment-specific, improving caching efficiency. The cleanup involved
removing the flag definition, updating the controller logic to
permanently use
the environment-specific ETag calculation, and refactoring the
corresponding E2E
tests to only cover the enabled behavior.
### 🚮 Removed
- **Flag Definition**
- The `etagByEnv` flag from `IFlagKey` in
`src/lib/types/experimental.ts`.
- **Conditional Logic**
- The check for the `etagByEnv` flag in `calculateMeta` method in
`src/lib/features/client-feature-toggles/client-feature-toggle.controller.ts`.
- **Tests**
- Test cases in `src/test/e2e/api/client/feature.optimal304.e2e.test.ts`
that
covered the disabled state of the `etagByEnv` flag.
### 🛠 Kept
- **Environment-Specific ETags**
- The behavior of generating environment-specific ETags is now the
default and
only behavior.
- **Tests**
- E2E tests verifying the functionality of environment-specific ETags
have
been retained and simplified.
### 📝 Why
The `etagByEnv` feature has been successfully rolled out and validated.
By
removing the feature flag and associated conditional logic, we simplify
the
codebase, reduce complexity, and make it easier to maintain. This change
makes
the improved ETag generation strategy a permanent part of the system.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
This PR cleans up the debugEtag flag. These changes were automatically
generated by AI and should be reviewed carefully.
Fixes#10557
## 🧹 AI Flag Cleanup Summary
This removes the `debugEtag` feature flag from the codebase. This flag
was used
to enable additional logging for debugging ETag generation for the
client
features endpoint.
### 🚮 Removed
- **Flag Definition**
- The `debugEtag` flag from the `IFlagKey` type in
`src/lib/types/experimental.ts`.
- **Conditional Logging**
- Removed logging statements guarded by the `debugEtag` flag in
`client-feature-toggle.controller.ts` and
`configuration-revision-service.ts`.
### 🛠 Kept
- **Default Behavior**
- The existing code paths for when the flag was disabled, which is now
the
only behavior.
### 📝 Why
The `debugEtag` flag was marked as completed with the outcome
"discarded". The
debugging functionality it provided is no longer needed. This change
removes the
dead code associated with the flag, simplifying the codebase.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
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
