Similar BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1634713
Generally on the pages where there are multiple entities, such as multiple VMs you can get buttons that are not relevant.
This is a design issue and cannot be "fixed" unless you want to do a major redesign of all the GTL screens and toolbars.
The check if a particular action applies to selected entities is performed when the button is pressed. A that moment a check should be done agains the whole list of the selected items one by one.
This is how the product is designed form the very early and how all the screen behave.
I'd refer to Loic to decide if we want to be "fixing" issues like this one. I am sure we can generate a lot of similar BZs for many of the list screens.
In this very particular case is might be possible to have a different toolbar based on selection in the left tree --> have a different toolbar when the "Orphraned" or "Archived" tree item is selected.
I am not sure how "hacky" doing that would be.
This PR https://github.com/ManageIQ/manageiq-ui-classic/pull/5128 could be a 'fix'.
Not exactly to Expected results, but the proper flash message will be displayed if
user tries to apply some power operation on an archived/orphaned VM from the list.
(In reply to Hilda Stastna from comment #6)
> This PR https://github.com/ManageIQ/manageiq-ui-classic/pull/5128 could be a
> Not exactly to Expected results, but the proper flash message will be
> displayed if
> user tries to apply some power operation on an archived/orphaned VM from the
That will help explaining that it is not possible. Best will be to remove the button.. Is it something we could do via RBAC as workaround?
There's no reason the button should not behave correctly on the single item page. In this BZ I do not see the reporter complaining about that case. I assume it works correctly.
RBAC workaround: I do not think that we can remove the button from a single page with RBAC. If you remove the permission via RBAC, it should remove the button from all pages.
I think that displaying the proper flash message as Hilda suggested is the right fix. It's consistent with other places.
*** Bug 1633732 has been marked as a duplicate of this bug. ***