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 🤷🏼
