Show identity alias in identity overrides list inside feature detail

[rolodato]

Is your feature request related to a problem? Please describe.

We currently support identity aliases to provide human-readable names for identities that might otherwise have meaningless IDs. These IDs are used in the identities list and details, but not in the list of identity overrides inside a feature (foo here is an identifier, not an alias):

Describe the solution you'd like.

If an identity has an alias, show it inside this page the same way we show it elsewhere.

Describe alternatives you've considered

🤷

Additional context

No response

[matthewelwell]

This is actually much harder than first anticipated since it would mean modifying the structure of the identity overrides in another dynamodb table that would be a bit of a nightmare to keep in sync for environments where there are a lot of identity overrides. For a bit more context, any update to the dashboard alias for a given identity would then also need to update all the identity override records in the flagsmith_environments_v2 table and any addition of an identity override would require the dashboard alias to be passed in by the client, or another query could be made to retrieve the alias.

Some other options that we have as a compromise:

1. We add a 'show dashboard alias' button next to each identity that will trigger the FE to make a request to get the identity from the API and show the dashboard alias. This is the 'easiest' option, but isn't overly useful.
2. We add a 'show dashboard aliases' button at the top which requests the identity document for each of the identities on the page. This would end up triggering N requests though, where N is the number of identity overrides shown on each feature. We're not able to search for multiple identities in a single request to dynamodb either though, so something like the following also wouldn't be possible identity_uuid_in=abc123,def456,....

We could also implement (2) without the need for the additional click to show the dashboard aliases, but I don't think we'd want to do this for each feature unless it was necessary.

To be honest though, option 1 is likely not that useful and option 2 is messy.

I will continue to think on this, but I'm not sure there's an easy option here.

There's an option that we actually store this data in postgres instead, but then if we want to expose this to our SDKs, we need to find a way to write this data from dynamodb / lambda back to postgres.

[rolodato]

There's an option that we actually store this data in postgres instead

This seems like the most feasible option. Option 1 is not a good solution and option 2 is not scalable. We could improve option 2 by introducing a cache between the Core API and DynamoDB but that adds all sorts of complexity for just this one feature.

but then if we want to expose this to our SDKs

I'm okay with never supporting this - so far the only use case for identity aliases is purely administrative, i.e. Admin API only. If a legit use case for exposing this to SDKs comes up, we can revisit. It would allow us to eventually support aliases in self-hosted as well?