frontend
frontend copied to clipboard
Add 'bulk unhide' in entity table, filter shown options
Proposed change
Adds a bulk unhide option in entities table, to go along with bulk hide option. (requested #12950)
Also this PR applies some logic to better choose which bulk options to show, instead of showing them all the time.
Hide Selected will only be shown if at least one selected entity is enabled and unhidden.
Unhide Selected will only be shown if at least one selected entity is enabled and hidden.
Enable Selected will only be shown if at least one selected entity is disabled by user or integration.
Disable Selected will only be shown if at least one selected entity is enabled.
Type of change
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [x] New feature (thank you!)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
Example configuration
Additional information
- This PR fixes or closes issue: fixes #12887
- This PR is related to issue or discussion: #12950 https://community.home-assistant.io/t/unhide-multiple-entities/557423
- Link to documentation pull request:
Checklist
- [x] The code change is tested and works locally.
- [x] There is no commented out code in this PR.
- [ ] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for www.home-assistant.io
Found one more interesting angle to this. Realized that having this unhide button allows users to unhide entities which are hidden by integration. We don't currently allow that in the entity registry settings, we disable the visibility selector for entries hidden by integration.
On investigation, I can't find a reason why user should not be allowed to manually unhide entities which are hidden by integration. It is supported by the backend, and it works as I would expect.
So I think this is fine, and as part of this PR I also changed the entity registry editor to allow user to unhide hidden by integration entity. That also fixes issue #12887.
We have to look at the layout, adding an extra button does not fit in all cases. Cramming 4 buttons into that is already borderline, let alone 5.
It doesnt fit on an iPhone Max:
The not Max:
We have to look at the layout, adding an extra button does not fit in all cases. Cramming 4 buttons into that is already borderline, let alone 5.
Maybe in small width condition choose a priority between enable vs disable and hide vs unhide? User should not need to see both options at the same time. Then we can reduce from 4 buttons to 3.
if(canEnable) {
<enable>
}
if(!canEnable && canDisable) {
<disable>
}
if(canHide) {
<hide>
}
if(!canHide && canUnhide) {
<unhide>
}
Discussed this with design, we should use an overflow menu if there are more than 3 items to display.
I don't think hiding enable/disable buttons is wise, as for some integrations it requires a restart or some time to process. It is not a risk free operation.
Discussed this with design, we should use an overflow menu if there are more than 3 items to display.
Hmm, that sounds a bit strange to me to be honest. Now when we select an item, we very clearly and visually see the options you can make with that selection.
If we hide these in the overflow menu, it seems like there will be no visual indication that new options have appeared there? Almost seems too obscure/hidden.
@matthiasdebaat @Madelena
In Dutch it's already broken, because the word geselecteerd pushes the trash can icon off the screen.
Hmm, that sounds a bit strange to me to be honest. Now when we select an item, we very clearly and visually see the options you can make with that selection.
These icons on mobile need a label. For example the curved left arrow doesn't explain to me that this enable an entity. Except for delete, trashcan is one of the few that doesn't need a label.
If we hide these in the overflow menu, it seems like there will be no visual indication that new options have appeared there? Almost seems too obscure/hidden.
The top bar changes so you can see that there are other options. On mobile I would advise showing the delete icon and the others in the overflow menu. And we need to delete the repetition of the word selected in the labels.
In Dutch it's already broken, because the word
geselecteerdpushes the trash can icon off the screen.
Hmm, that sounds a bit strange to me to be honest. Now when we select an item, we very clearly and visually see the options you can make with that selection.
These icons on mobile need a label. For example the curved left arrow doesn't explain to me that this enable an entity. Except for delete, trashcan is one of the few that doesn't need a label.
If we hide these in the overflow menu, it seems like there will be no visual indication that new options have appeared there? Almost seems too obscure/hidden.
The top bar changes so you can see that there are other options. On mobile I would advise showing the delete icon and the others in the overflow menu. And we need to delete the repetition of the word selected in the labels.
Ok, so to confirm I understand correctly:
- On narrow, all options except delete go to overflow menu.
- We will still show all unavailable options in the overflow menu, but as disabled rows?
- Wide view keeps the current text labels, no overflow menu, but the word selected is removed, so it just say
EnableDisableHideUnhide? And we need new translate key to redo all localizations?
Is it worth considering a bulk delete as well, or is that too confusing to have with bulk remove in the same set of options?
No way to delete multiple entities (like helpers) at a time currently I think.
Maybe don't make it an overflow like we normally have, with 3 dots ..., but a text button With selected 🔽 ?
Is it worth considering a bulk delete as well, or is that too confusing to have with bulk remove in the same set of options?
No way to delete multiple entities (like helpers) at a time currently I think.
I don't fully understand. Why do we need 2 buttons, instead of one to delete/remove entities? If it's a label issue we can rename it to delete.
Maybe don't make it an overflow like we normally have, with 3 dots
..., but a text buttonWith selected 🔽?
Let's keep it with the overflow menu. In our latest design exploration we came with the same design.
I don't fully understand. Why do we need 2 buttons, instead of one to delete/remove entities?
Well I guess it could be the same button, but they are different operations, at least currently. Didn't know if we want to make them the same.
E.g. for helpers, you can't currently "remove" them with that button, you have to open them one by one and hit the "delete" button individually.
Remove is only for entities which are not currently available (probably butchering the terminology there). Should we make deletable entities (like helpers) be deleted in the same operation as the current remove button?
Should we make deletable entities (like helpers) be deleted in the same operation as the current remove button?
I would say yes, @karwosts and @bramkragten what do you think?
The most destructive thing is delete, so I would change these dialogs to delete if there is a deletable entity selected. If not, we should keep it as is.
Ok made some updates from feedback. Now have:
Narrow:
Normal (does not fit all buttons):
Wide:
I'm going to leave bulk delete out of this for now, getting a little too many changes here for one PR,
I'm working on a bigger overhaul of our data tables, I would like to incorporate this in there, are you ok with that?
I'm working on a bigger overhaul of our data tables, I would like to incorporate this in there, are you ok with that?
Sure, no problem. Feel free to close this, or modify it, or whatever you want to do, fine with me :+1:
I'll withdraw this now as it appears to be satisfactorily implemented in the new entities table. Thanks Bram.
