[Catalog] Feature- Remove or hide delete option from menu (Headers)

[MiguelRamBalt]

We want to delete the menu from the header in catalog when you select an Api.

Possible Implementation

We can add a configuration in app-config.yalm file under the catalog section, and then We can create a hook in order to read that specific configuration.

Context

We want to create that menu configurable because we are planning to delete entities from another section, so We can modify that section just adding or removing a attribute.

[timbonicus]

To be clear, are you talking about hiding the context menu shown here, only for API kinds?

And is the desire to hide the whole menu, including other things that may be in there, or only to disable the Unregister entity option? Perhaps something like a readonly flag for an entity or access control as in #3218 could signal that unregister is not available as an option (and be manually overriden elsewhere)?

[MiguelRamBalt]

Hi @timbonicus !

Yep that's the whole menu We want to hide, that's because We customize each entity using EntityPageLayout and We give the right access to each user in that way. We currently working on a contribution but I'm little blocked because I'm using this pattern const config = useApi(configApiRef); const supportConfig = config.getOptionalConfig('catalog'); in order to get that configuration from app-config.yalm file, but I can't get the configuration from that file and I don't know if that is the right solution.
I would like to know you point of view about that.

Thanks!

[MiguelRamBalt]

@timbonicus I created this PR #5662 regarding this enhancement.

[timbonicus]

Sorry, I'm still finding this quite unclear. Hiding the menu itself doesn't seem like the right approach. I was proposing a way to mark certain catalog entities as forbidden to unregister. Then, as a byproduct, the menu item (and perhaps the whole menu if that's the only menu item) goes away.

We customize each entity using EntityPageLayout and We give the right access to each user in that way

Would you mind describing your use case a bit? Do you mean that you want RBAC for catalog entities, where access to unregister is only available to certain users?

To your other question, the config should be exposed by the relevant plugin (catalog, in this case) rather than in the core package. You can see the current catalog configuration available from catalog-backend, but this would be frontend config so a similar config.d.ts file in plugins/catalog instead.

But again, adding a flag to hide something on the UI doesn't seem like the right approach. This wouldn't prevent backend calls from still succeeding, for example. That would be better accomplished with something like the readonly catalog flag. You said originally that you want to hide it for API kinds specifically, which a generic flag doesn't achieve either.

It seems like either a readonly field on entity metadata, or entity RBAC, would be the right solution depending on your use case.

[MiguelRamBalt]

Hi @timbonicus

Answering your questions, We want to remove that menu for all entities, inside of each entity We are going to determine if the user have access to delete. The approach you suggest is a little hard to implement that because we need to modify all the entities already created and pass that property for each of them., Currently We are working on create a users groups and map to them the entities. That's way We give this proposal.

[MiguelRamBalt]

this is another issue related to #5658

[stale]

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.

[stale]

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.