Closed alternone closed 3 weeks ago
Hi @alternone,
thanks for the feature request. Definitely valid points.
persistent volumes with real names lead to issues due to special characters like white spaces (this should be considered and made more robust (by e.g. always use internal user ID instead or escaping characters of usernames)
A good first step will be to save a reference to the name of the PVC to the database. That's only a small database migration script. Currently, the persistent volume name is derived from the username on demand as you've mentioned. A saved reference in the database would allow us to change the naming algorithm of PVCs without the need to migrate "old" PVCs. Old PVCs can keep their name and new persistent volume claims can then use new naming algorithm.
The idea of having different fields aligns with our strategy.
identification field : to map company internal IDs and to be used for persistent volumes and unique IDs
I'd only use the identification field to map the user from the identity provider to our internal user. For persistent volumes, I would not rely on external values. Instead, I'd use a randomly generated ID or our internal user database ID for the PVC name.
name field: to map real names for UI displaying in profiles and access control
Makes sense to have a different field for display name.
e-mail field: for possible upcoming features like mail notifications (from e.g. jobs) , announcements, access invites
👍
Currently the mapped username from identify provider will be used for several use cases with some limitations:
This leads to some issues.
Thus I would recommend to support 2 or 3 synchronization fields for identity managements:
PS: I agree for persistent volumes a migration script is required tp upgrade existing persistent volumes when switching to a version that has a different mapping caused by this feature.