Nit: add newline after Flow declaration

Can you provide pictures of the light mode please?

That's a good question! But I have to fix the light mode first...

Do we really need a new family of colors for invite links? Did you try finding any existing families we could use? cc @ted

For inviteLinkHeaderColor, the only other entry with the same color in dark theme is listSeparatorLabel - definitely not a good match.
For inviteLinkButtonBackground, there are a couple other options and there's one which matches both themes modalSeparator - but I don't think we should use it.

Do you have a suggestion of how we should approach this?

For me it seems like spending too much time on such a simple thing as colors isn't effective. We should probably start with creating consistent design, with a couple of predefined color pairs (light and dark) and then update all the components to use them.

Do you have a suggestion of how we should approach this?

My general feeling is that invite link buttons and headers should not be specific to invite links. We should rely on a consistent design system for things like buttons and headers.

I'm pushing back here because this pattern of "every engineer introduces their own button for their screen" leads to an incredibly fractured design system.

Can you sync with @ted to figure out if invite link button / headers REALLY need to be distinct? If yes, can we come up with a more generic name for them here that describes what the button / header looks like, and how it can be reused?

What designs are you using? I see a different message https://www.figma.com/file/a1nkbWgbgjRlrOY9LVurTz/Comm-%2F-Desktop-app?type=design&node-id=12485-235674&t=5pjj80bZzIrM3YOD-4

The state depends on the role of a user. This screen is for regular users https://www.figma.com/file/a1nkbWgbgjRlrOY9LVurTz/Comm-%2F-Desktop-app?type=design&node-id=12485-239352&t=mSlYMlGynVnD8xDZ-0

Talked with @ted and he suggested that:

1. inviteLinkLinkColor as a new color should stay
2. inviteLinkButtonBackground - we could use instead panelSecondaryForeground. Which makes sense from colors point of view, but we should then find a new name as using foreground as a background is probably worse than introducing a new color.

As @ted is off for now, I don't think it makes sense to block this diff on this change.

I can't find the code where this is changed based on the permissions

It's a lot later in the stack D7885