✨ [FFL-2857] Feature Flags tab — team filtering + token revocation (stacked PR 4 of 4) - #4932
✨ [FFL-2857] Feature Flags tab — team filtering + token revocation (stacked PR 4 of 4)#4932kellyw1806 wants to merge 1 commit into
Conversation
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 850a642 | Docs | Datadog PR Page | Give us feedback! |
c88291e to
2a98437
Compare
4c49f6e to
16b1216
Compare
Bundles Sizes Evolution
|
2a98437 to
da1a176
Compare
e4698ab to
c960f4a
Compare
BeltranBulbarellaDD
left a comment
There was a problem hiding this comment.
Overall looks good! Left some comments.
| function MyFlagsSwitch({ view, identity }: { view: FlagCatalogView; identity: FlagIdentityState }) { | ||
| // Without the signed-in user's UUID there's nothing to compare a flag's creator against, so the | ||
| // filter could only ever match nothing. Disable it and say why, rather than offering a toggle whose | ||
| // only effect is to empty the list. | ||
| const unavailable = !identity.loading && !identity.userId |
There was a problem hiding this comment.
I wonder, there is no way to see this component without being authenticated right? If we weren't authenticated the tab would fail before. I think we can remove these kinds of checks from the lower level components and in the root layout we check the auth, if not auth we show login screen, else all components are authenticated?
There was a problem hiding this comment.
Or in the context.
There was a problem hiding this comment.
Oh, this was not an auth check, but more of a UX guard. The "My Feature Flags" filter needs the user's id to work. If we don't know it yet (identity is still loading or failed), the toggle would do nothing when clicked, so i thought it would be better to just disable it and show a tooltip explaining why. what do you think?
There was a problem hiding this comment.
But could we be logged in here but no user id?. Even still, if we were to check this in the context for example we could use the same check right? So we wouldn't have to check it in the component but just get it from the context? That way we can re use it? Just sharing some thoughts, you are free to discard it 🙂
There was a problem hiding this comment.
I now understand that catalog and identity are separate requests. I wonder the above, how possible would it be to save it in the context and re use them.
There was a problem hiding this comment.
hmm, the identity is already shared through the context (both the filter bar and catalog view read it from there), and the only thing left in the component is a one-line "do we have a user id yet" check used by a single toggle. so i think we might not need to try to find more places for context reuse here?
c960f4a to
439df75
Compare
Filter the flag catalog by owning team (teams_read scope + flag identity), and revoke the OAuth grant at Datadog on disconnect rather than only clearing local tokens. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
439df75 to
850a642
Compare
Motivation
Stacked on #4912 (flag overrides). Adds team/creator filtering + per-flag descriptions to the Feature Flags tab, plus production OAuth support and token revocation on disconnect.
Stack (review bottom-up)
mainffl-2597mainffl-2596Changes
created_by=<uuid>; "My teams" →tags=team:<handle>. Identity (user UUID + team handles) comes from/api/v2/current_user+/api/v2/team?filter[me]=true. "My teams" is a checkbox dropdown showing an "N selected" summary.descriptionattribute), with a "Show more" expander that only appears when the text is actually clamped.getClientId— staging vs prod); site picker trimmed to US1 + Staging./oauth2/v1/revoke— revokes the refresh token, clears local tokens either way).teams_read(viainvalid_scoperedirect or an authorize page-load failure).DEMO
Note, we can now choose between datadoghq.com and staging. There are also filters for My Feature Flags and My Teams. Descriptions are fetched as well.
Screen.Recording.2026-08-10.at.1.26.56.PM.mov
Checklist