fleet
fleet copied to clipboard
fleetdm
Display `InfoBanner` component if filtered policy id does not exist on hosts page
Currently if a user tries to navigate to the hosts page using a URL with a non-existent policy_id query param, the policies filter button appears without a name.
hosts/manage/?order_key=hostname&order_direction=asc&team_id=2&policy_id=999999&policy_response=passing:
Goal
As a user navigating to the list of hosts filtered by a policy, I want to know when a policy no longer exists.
Requirements
- User sees an
InfoBannercomponent displaying the following message:The policy does not exist. Head to the Policies page to see a list of policies.
Figma
https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=9617%3A316777
noahtalerman: I moved this out of the original issue description for safe keeping.
The button allows the user to clear the invalid policy filter without editing the URL and refreshing the page so it does provide some utility. Still the UX can be improved with a more helpful banner that better informs the user of the problem. One possibility is to replace the policies filter block (policy status dropdown and button) with a banner or other element that the user can click to clear the filter and send the user to the default manage hosts page.
As part of this ticket, it would also be a good idea to examine how other query param filters handle non-existent entities (software, mdm, operating system) on the manage hosts page and try to apply some standard approaches.
User sees the 404 page if they navigate to the Hosts page with a non existent policy_id
@lukeheath I think we want to apply this same behavior for all query parameters in which the entity (software id, policy id, etc.) no longer exists. What do you think? Is this normal behavior for a web application?
@noahtalerman I'm not sure a 404 page is the way to go here. That would make sense if the user was trying to load a policy details screen for a policy that no longer exists, because that page no longer exists (404). However, in this case we're attempting to pass the policy id as a query param on a page that does exist, hence not a 404. Instead, if an entity is passed as a query param that no longer exists, I suggest we pop up an error flash message stating that it no longer exists, and show the page without the filter applied. Thoughts?
page that does exist, hence not a 404
Makes sense.
suggest we pop up an error flash message stating that it no longer exists
@lukeheath what do you think about showing the user the grey information banner instead of error message?
This way, the user is informed "something no longer exists" instead of "something went wrong (red error)."
@noahtalerman Good point, that UI element does make more sense. The only concern I have is that we don't know if the policy ever existed or not. We just know it doesn't exist now. Should we change the copy to "The requested policy does not exist. Head to the Policies page to see a list of policies."?
we don't know if the policy ever existed or not.
Ah, good point.
@lukeheath I like your suggested copy. I prefer removing "requested" to shorten the message:
The policy does not exist. Head to the Policies page to see a list of policies.
@lukeheath do we want to a) prioritize #8152 to this release which is the backend portion of this (measure twice cut once) or b) remove this from the release?
@RachelElysia Let's defer this ticket for now. Moving back to the estimated column.
This is the behavior if the software doesn't exist. I had a bunch of fake hosts I deleted, software inventory wasn't updated yet, I clicked a software that was on hosts I deleted only, and got this spinning page of doom.
Do we have a larger ticket for consistent API error states? I know errors came up again in #8306 and would be great to track our progress. @lukeheath