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.
## About the changes
Previous PR: https://github.com/Unleash/unleash/pull/10439 introduced a
bug not allowing to update the strategy name
This PR modifies a test to also validate the change of strategy and
fixes the problem
## About the changes
When stickiness was set to empty or undefined while updating a strategy
via API the stickiness would be lost.
This adds a validation step after creating a strategy, that updating
with the same data used to create the strategy yields the same result.
The main change was lifting the default logic from the store layer to
the service layer and adapting tests accordingly
## About the changes
Follow up on https://github.com/Unleash/unleash/pull/10430 this PR
adapts documentation.
---------
Co-authored-by: Melinda Fekete <melinda.fekete@getunleash.io>
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>
This makes it easier to navigate inside the preview site (cause it stays
in the preview instead of jumping to the docs website), and it also
helps detecting broken links if we change the landing page (since the
one in docs.getunleash.io will still exist).
When querying invalid tokens we might catch them for a while to reduce
database load. Being able to identify the token can help understanding
what's going on or the client using that token
Log looks like:
```
[INFO] /services/api-token-service.ts - Token default:development.3ef3... rate limited until: Tue Jul 29 2025 09:53:47 GMT+0000 (Coordinated Universal Time)
```
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"
/>
## About the changes
We've been using vitest for coverage and we use a github action to push
results to coveralls, so this should work just fine
Unlocks form-data to be able to fix
https://github.com/Unleash/unleash/security/dependabot/267
Also, removing coverage from PRs to avoid running tests twice
