frontend: allow multiple deletes on ResourceTable

[farodin91]

Fixes #1640, #1604

• allow rowselection
• externalize logic

screenshots:

folllow up:

• support more actions such as restarts
• support auth check
• support plugin extensions

[skoeva]

Thanks! minor nit, can you change the following file name:

ResourecTableMultiActions.tsx
⬇️
ResourceTableMultiActions.tsx

[sniok]

Great improvement, thanks! I've tried it out and works well. Just left a couple of small suggestions

[farodin91]

I found an issue. It should be fixed with the next commit.

[joaquimrocha]

My concern here is how do we employ our usual UI philosophy of not showing the controls for which the user has no permissions. i.e. how to make sure we don't show the delete button if we are in a role where a deletion will fail? (some users deploy Headlamp as a read-only UI)
Should we make an exception here and still allow users to select multiple rows but then check if there are no permissions to delete those items and, if no items can be deleted, we either 1. place a disabled button with a tooltip explaining there's no permissions; 2. we show a message right away in the actions area explaining there's no permissions?

[farodin91]

@joaquimrocha Is their an efficient way to check all items for permission?

[farodin91]

We could also show in the dialog for which resources you have the permission as you can have the permission for some and for some you have no permission.

[farodin91]

I did thought a bit about it during the implementation, but I think their is no perfect way. So, I left it away.

First I could a global setting to show it or not and then mark it as beta and ask for feedback.

[joaquimrocha]

I did thought a bit about it during the implementation, but I think their is no perfect way. So, I left it away.

First I could a global setting to show it or not and then mark it as beta and ask for feedback.

I think we can ask on Slack. But it's true that there's no easy way to do this very efficiently, because theoretically I guess one could be allowed to delete just a single resource in a namespace where nothing else can be deleted in one's role, right?

I think we could also implement your idea of a switch in settings as you say, but I guess the idea of not showing the delete button is only relevant in environments where Headlamp is read-only most of the time, and those tend to be when Headlamp is deployed in-cluster or as a service. So what would be cool here is a way for running Headlamp with pre-filled settings, but we don't have a good solution for this ATM.

I would say it's more important to have bulk deletion than a way to avoid it in RO envs, so we can keep your solution if there's no way or half way to check for permissions in bulk...

[farodin91]

I think we can ask on Slack.
Sounds great.

But it's true that there's no easy way to do this very efficiently, because theoretically I guess one could be allowed to delete just a single resource in a namespace where nothing else can be deleted in one's role, right?
yeah, also one namespace is allowed another is prohibited.

For the switch: Do you think it is better to use a single switch or a switch for every cluster?

[joaquimrocha]

For the switch: Do you think it is better to use a single switch or a switch for every cluster?

It would be a switch for every cluster, but I don't think we should add the switch for now, as it won't make much difference since it's the end user themselves, not an admin, that would have to set the preference. And there's no big gain in that, since our concern here is to have people eventually trying to delete resources in a Headlamp that's been deployed for them, not in their own desktop deployment.

So for now we can leave that functionality as an exception to our overall UI controls philosophy IMO.

[farodin91]

@joaquimrocha What is your plan now? Keep the current state and probably add a beta flag to it. Or do we need to do more merging?

[farodin91]

@joaquimrocha I added a beta mark to deleting items

[joaquimrocha]

@joaquimrocha What is your plan now? Keep the current state and probably add a beta flag to it. Or do we need to do more merging?

Sorry I couldn't reply earlier, and that I wasn't clearer in my previous message.

In the meanwhile, I have a few more points to discuss:
I was wondering if we should enable clicking the row to select, and only show the check boxes column if one row is selected, but maybe this hides the feature too much? I can talk to our design team next Wednesday and get their feedback too.

I don't think a beta flag is needed, but I wonder if we should have a REACT_APP*_ flag to enable it (we use this to change some things, like the product name). This would enable/disable the feature be for all clusters, so it could give the ability for someone deploying a read-only Headlamp to turn this feature off.

Some changes needed already:
After I tested it now, I notice that there's one notification per pods. This is a problem, since it will not only look noisy but also it will be impossible for the user to click cancel in more than a few. So the delete actions should be gathered in one action "Deleting items my-pods-123, my-pods-321, ... [Cancel]". We have a similar case when we apply multiple resources from the create dialog.

[farodin91]

@joaquimrocha I've grouped the deletion. "Event shows a number"
I added a flag.

I was wondering if we should enable clicking the row to select, and only show the check boxes column if one row is selected, but maybe this hides the feature too much? I can talk to our design team next Wednesday and get their feedback too.

I just used the design which react table is providing.

[joaquimrocha]

Left a couple of comments but overall is looking good.
Also, the UX feels very slow. Takes sometimes 2 seconds for an item to be selected when in dev mode. Dev mode is admittedly very slow, but maybe @sniok knows whether there's something we can do to speed this up.

[farodin91]

@joaquimrocha i merged the branch table-pref into this branch and it was quite fast.

[farodin91]

@sniok Do you have any idea how to fix the checked behavior after merging #2620, it stopped working?

[sniok]

@sniok Do you have any idea how to fix the checked behavior after merging #2620, it stopped working?

sorry about that, I'll make a PR with a fix

[sniok]

@farodin91 I've opened a PR with your implementation for row selection in the Table along with my fixes for it #2648

[farodin91]

thanks

[sniok]

@farodin91 you could rebase this PR on top of 'table-selection' branch already to see if it works as you expect

[farodin91]

@sniok Should be updated.

[farodin91]

@sniok works fine for me.

[sniok]

tested on various resources, works great!

[joaquimrocha]

The failure here is due to an i18n dangling translation that I fixed in main now. So I will merge it.