Allow customizations to the User Profile page

Feature Suggestion

Hi there! I’m currently working on a feature which will allow users to update their user profile with more details that they can fill out in the User Settings page. I wanted to see if this is something I could integrate and contribute to the Backstage codebase/what sorts of things I could make configurable so that this is helpful to everyone. An example flow would look like:

1. I update my profile on my user settings page: heatheralee. I add information like: my preferred modes of communication, my time zone, a short blurb about me.
2. Someone else searches for the UserEntity heatheralee and finds my UserProfileCard as well as the other information I’ve added in step 1.

Possible Implementation

After some investigation, the below suggestion feels unnatural to Backstage and am open to suggestions on where to best store this data and where to allow for authoring of content. Will update this issue with another proposed implementation.

1. Allow users to decide which fields users can author about themselves by adding field name and field type to app-config.yaml file. These fields will come from a predefined set (tbd). 2. Update plugins/user-settings/src/components/SettingsPage.tsx to iterate through app configuration in step 1 and render form fields. 3. Once user fills out these fields, update the UserEntity profile to contain added information. 4. Update plugins/org/src/plugin.ts to include new cards which render custom fields, and allow users to add this in packages/app/src/components/catalog/EntityPage.jsx.

Context

With this change, we are enhancing the user profiles with more information. One example of why this is helpful so that when users find owners of services, and they click on the owner username, they can get more information about the owner.

Screenshot of potential implementation

The fields pictured above are up for discussion – would love to hear about what fields would be helpful for your org.

[timbonicus]

Hmm, let me clarify my thoughts and come back to your question.

I imagined extending plugin-org to add a group/user management frontend in Backstage that’s adaptable to different backend systems. The backend system may be LDAP, GitHub, Okta, or a custom API such as at Spotify.

The concept of integrations enable Backstage to read or publish data to various providers. Reading org data is already provided in some cases, such as the GithubOrgReaderProcessor. The publish part of the concept is only used by software templates so far, but I can imagine integrations optionally providing org write capability.

So imagine the UI emits a User or Group entity, with appropriate relations, which is passed to a write-supporting org integration to interpret and publish the changes to the external system. The updated entity is then read back through the normal catalog process.

This wouldn’t be ideal at the moment, since the catalog refresh runs at a fixed rate and wouldn’t pick up the external change right away. That will soon change with the catalog/next work. It has a concept of EntityProvider which allows entity updates more realtime than they are today.

So to get back to your question - in this scenario, Backstage still pulls data from org integrations as in (2), and supports edit/push via write-friendly org integrations which asynchronously update the catalog once complete. There’s a slight, hopefully minimal, delay for changes to be reconciled. Or perhaps the write integration could interact with the catalog to trigger an immediate, synchronous refresh for the entity.

I paint this picture imagining a single org integration and data source. I think you’re alluding to a situation with multiple org data sources. In Spotify’s case, even though there are multiple underlying data sources, this is still managed through a single backend system that synchronizes them all and provides a write API, so there’s no further complication.

A situation with actual multiple org data source becomes less clear. Are User and Group entities ingested with an annotation that indicates their backing source, so updates can be pushed to the appropriate provider? Something like edit-url? We would only allow a User ingested from one provider to be added to a Group from the same provider? There are some questions to be answered.

[timbonicus]

I agree wholeheartedly with this idea! I think the suggested implementation may be troublesome since Backstage does not want to be the source of truth for user information - that should instead be your user management system (LDAP, Github teams, etc) that is then wired into Backstage. I’d say it’s best for User entities to be loaded from that system with as little manipulation as possible, so that the source of truth is maintained.

That being said, it makes total sense for user management to be done through the Backstage UI (since this is just another infrastructure tool, which Backstage shines in bringing together). I imagine this could be a high-level User or Group editor that supports different integrations for common user management backends. Then, as others mentioned here, your user profile in that backend system is transformed for frontend display. Maybe this is your LDAP profile, Github README, etc. This could even be edited in Backstage but have data posted to the backend system. We have exactly this internally at Spotify.

There’s some distinction to be made between the SettingsPage mentioned, which shows information for my own logged in identity, and User entity pages from the catalog, which can show user information for any user in the catalog.

Like the idea, but first we want to enable the user-settings page to populate more information that we can query from the auth provider. This may related to the identityApi which currently is very basic info included.

I think this may be misguided - auth providers are meant to handle logging in users, not populating User entities in the catalog. There’s conceptually confusing overlap since some auth providers also have extended profile information for users and groups, but Backstage is designed to ingest User catalog entities with processors rather than auth providers. Using the latter would imply that you only have full user profile information for users that have logged into the system.