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"
/>
Adds "change:" to the beginning of all changes and does some work to
align the use of compononents and structure across them (supersedes
https://github.com/Unleash/unleash/pull/10260).
In doing so, I have also added new and legacy variants for all different
change components, because this has required some hierarchy
restructuring every now and then. A reason for doing that was adding the
correct wrapping behavior for components, such that on smaller screens,
we wouldn't entirely blow out and make the kebab menu invisible and
inaccessible.
It also makes it so that we switch to full-width change view earlier (at
breakpoint md instead of sm), because at sm, a lot of stuff got hidden
before we switched to full-width.
Most changes are trivial updates; I've called out bits of the code that
are not in comments.
Rendered, it looks like this:
<img width="1203" alt="image"
src="https://github.com/user-attachments/assets/36bed974-99da-4d8d-a881-ea9df7797210"
/>
One interesting and potentially quite useful side-effect, is that all
change types now use the exact same set of components in the same
fashion, as evidenced by this screenie where I've added outlines to the
hierarchy:
<img width="1020" alt="image"
src="https://github.com/user-attachments/assets/685fefcc-af7e-4697-b8f3-8260af1e2a84"
/>
The one difference is that components without a diff place the "more"
kebab menu one layer further inside to facilitate prettier wrapping (the
kebab menu can stay on the same line as the other text when wrapping):
<img width="238" alt="image"
src="https://github.com/user-attachments/assets/2b8d3174-06a8-4ad4-b366-cea97720deda"
/>
We're migrating to ESM, which will allow us to import the latest
versions of our dependencies.
Co-Authored-By: Christopher Kolstad <chriswk@getunleash.io>
As of PR #8935, we no longer support both text and title, and confetti
has been removed.
This PR:
- removes `confetti` from the toast interface
- merges `text` and `title` into `text` and updates its uses across the
codebase.
- readjusts the text where necessary.
Refetch actionable change requests whenever you perform an action on a
change request. This ensures that the change request notifications are
up-to-date for you. Of course, it can still get out of sync if someone
else performs an action on the change request, but that's more of an
edge case.
Added conflict count to CR metrics and CR id.
Something to think about:
There was idea that we can aggregate this data based on CR id, but CR id
is just a number from 0 to x. So it will not be unique across instances.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This changes the two interfaces IChangeRequest and
IChangeRequestSchedule to be union types instead of interfaces. It also
extracts the constituents of those union types into proper types
themselves (so that they can be used in function type signatures etc).
It also updates the type names.
This turned out to be more work than I had imagined, but I think the end
result pays off, giving us more type safety and control.
I wanted to use just `ChangeRequest` for the IChangeRequest type, but
that caused issues due to naming collisions with the `ChangeRequest`
component that we have, causing tests to fail. I've named it
`ChangeRequestType` as a potential solution, but suggestions are
welcome.
The relevant changes are in
`frontend/src/component/changeRequest/changeRequest.types.ts`.
Everything else is updated references and some necessary refactoring to
respect the new types.
The button doesn't do anything at the moment, but it's there visually.
Because this uses the same button as the dual-function button for
approve/reject, I extracted that component into a reusable
"multi-action" button. I could have copied the code wholesale, but it's
a complex component, so I thought this would be a better solution.
I'll add the dialog in a follow-up PR. This one already has a lot of
changes.
Visual:
