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
Internally token types are still identified as CLIENT, therefore when we
filter the ones we're allowed to see, we should still consider them as
CLIENT tokens not BACKEND tokens. This is internal until we can fully
remove CLIENT with the next major.
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>
## About the changes
Add some **info** logs prefixed with `[etag]` so que can control them
and with this investigate the increase in traffic after the new etag
implementation.
