This PR adds config support for differentiating multiple categories of table owners in the Amundsen UI. For example, if an Amundsen instance wants to differentiate human users who are responsible for remediating operational issues with a table from non-human team or service emails.
To implement this, we propose supporting open-ended owner categories identified by a name and a definition text, to be configured in non-open-source code. A future PR will then update the relevant React components to render differently when owner categories are provided, while preserving current behavior for Amundsen instances that don't want to display different owner types differently in the UI.
Add OwnerCategory interface
Update User interface to support passing other_key_values field that already exists on the backend's User model
Motivation and Context
At Lyft, we'd like to be able to differentiate human-user table owners--who could actually be contacted to address data quality problems--from non-human owners.
How Has This Been Tested?
Existing unit tests and linting pass. This PR doesn't implement any UI changes, so doesn't create any new tests. I locally tested using these new configs to render differently in the React app, but plan to put the actual React changes in a separate PR.
CheckList
[x] PR title addresses the issue accurately and concisely
Description
This PR adds config support for differentiating multiple categories of table owners in the Amundsen UI. For example, if an Amundsen instance wants to differentiate human users who are responsible for remediating operational issues with a table from non-human team or service emails.
To implement this, we propose supporting open-ended owner categories identified by a name and a definition text, to be configured in non-open-source code. A future PR will then update the relevant React components to render differently when owner categories are provided, while preserving current behavior for Amundsen instances that don't want to display different owner types differently in the UI.
other_key_valuesfield that already exists on the backend's User modelMotivation and Context
At Lyft, we'd like to be able to differentiate human-user table owners--who could actually be contacted to address data quality problems--from non-human owners.
How Has This Been Tested?
Existing unit tests and linting pass. This PR doesn't implement any UI changes, so doesn't create any new tests. I locally tested using these new configs to render differently in the React app, but plan to put the actual React changes in a separate PR.
CheckList