Customize the Entity context menu in Catalog

[SuganJoe]

In the Expedia group, we don't use the "unregister entity" or other menu options as we have a different way of deleting entities in our setup. So, for some organizations which don't use the unregister or inspect entity, it must be removable and all other menu items must be customizable for example e.g. badges in the menu item.

Feature Suggestion

To help with the above use case, it's better to not hardcode the menu items like here and give the users option to customize the items in the menu by passing custom values from the entity page, the same way as the extra menu items options here

Possible Implementation

Add "unregister entity", "inspect entity" via "UNSTABLE_extraContextMenuItems" similar to badges from the entity page instead of hardcoding it here

Do similar checks here to disable the "Unregister entity" button in the entity page itself, so that users have control over the menu item.

Context

To make the entity context menu customizable.

I would like to work on this if you all think this approach works.

[gman0922]

@benjdlambert @emmaindal any thoughts on this issue? :)

[emmaindal]

Thanks for opening this issue @SuganJoe I think the capability to compose the context menu makes totally sense to me. I see the UNSTABLE_extraContextMenuItems is prefixed with UNSTABLE so not sure if the plan is to deprecate that. In general for how to compose it, I'll leave it up to @backstage/maintainers, as I can imagine there is some patterns (you mentioned one of them) that one can follow for the catalog composability.

[jhaals]

Hi! There's an option for disabling the unregister button :)
See https://github.com/backstage/backstage/blob/master/plugins/catalog/src/components/EntityLayout/EntityLayout.tsx#L146 which can be passed into as props to EntityLayout.

[SuganJoe]

@jhaals yes you are right but it will only disable the button in the menu, but we are aiming not to show the item in the menu/remove it.

[benjdlambert]

Wondering if we can make https://github.com/backstage/backstage/blob/master/plugins/catalog/src/components/EntityLayout/EntityLayout.tsx#L147 boolean | VisibleType and then deprecate the boolean in favour of type VisibleType = 'visible' | 'hidden' | 'disabled' instead? The name of that is probably not great, so feel free to pick something better :)

[SuganJoe]

@benjdlambert tried locally and this works perfectly for all scenarios. Can I get the issue assigned to me?

Do you mean to initially keep disableUnregister as boolean | VisibleType both and at a later time, deprecate the boolean and just use VisibleType. Is it because the adapters of the code need a change if we directly switch from boolean to VisibleType?

[benjdlambert]

We should support both and do the checking inside the component to see if it's a boolean then use the existing behaviour, but if it's of a string type then check what the string is set to and do the new behaviour. Maybe you could also console.warn if boolean is provided with a deprecation messaetg.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.