Notify end user when device is failing one or more policies via the menu icon

[noahtalerman]

• customer-honoria: Gong snippet: https://us-65885.app.gong.io/call?id=5893185207303179971&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A884%2C%22to%22%3A902%7D%5D
• @noahtalerman: User requested this because we assume that honoria asks their end users to go to Fleet Desktop to find remediation instructions for failing policies. We think end users don't notice when they start to fail policies. The red circle 🔴 emoji next to "My device" isn't enough because they have to click on the Fleet icon to see it.
  • @noahtalerman: In the interim the IT admin can coach their end users to click on the Fleet icon and if they see a red circle emoji this tells them that they're failing policies.
  • @noahtalerman: Eventually Fleet could add an indicator on top of the Fleet icon itself so that the end user can see they're failing policies without having to click on the icon. Fleet could also hide the icon unless there's a failing policy.
    • @allenhouchins: Hiding the Fleet icon entirely might be a tricky UX problem. What if there's self service software? How does the end user open their My device page if they're not failing any policies?

User stories

• Fleet Desktop: Add indicator to Fleet icon when device is failing policies #25548

[noahtalerman]

@chiiph do you know what data Fleet desktop needs to update the taskbar icon? Is this something Fleet desktop already has access to?

[chiiph]

There might be a hacky way to get the red dot without changing the Fleet side of things. However, the right way to do this is to expose a new set of APIs that Fleet Desktop has access to to provide this information and will be the foundation to later on show other data.

[zwass]

If the current library doesn't support icons for submenus, we'll just use text (eg. My Device (failing policies)) for the first iteration.

The device API does include policy information. If the request fails, show some text to indicate that it was not updated (no need to get fancy with changing states).

[chiiph]

The device API does include policy information.

I assume you've considered this, but please bare with me just for the sake of making sure we are on the same page:

So far we've had the UI talking to the device API. Fleet Desktop only links to the UI. The vaguely discussed plan was to create a new API for notifications for Fleet Desktop to talk directly to Fleet server. That's also where we would get remediation steps and so on.

We can reuse the API in Fleet Desktop, but that will generate a dependency between two teams: if the API needs to change for something related to interface, we'll need to make sure to keep it backwards compatible with Fleet Desktop (as, even if we update Fleet Desktop as well, an old one might still try to use it).

If we instead create a specific API for this data, it adds a bit of work but it should let the interface team move faster.

Another side of this is that with this API we are also pulling other things such as software data, which won't be needed for the tray. We should make sure we simulate a lot of Fleet Desktops asking for host details at an interval if we go this way.

With this in mind, you rather we reuse the host details API in Fleet Desktop?

[lucasmrod]

+1 to all the above.

We should define a separate endpoint for Fleet Desktop only, for fetching the policies.

Why?

1. What Tomas said above regarding API compatibility and not breaking Fleet Desktop with new Fleet Server releases.
2. Scale: Keeping "UI" and "Fleet Desktop" APIs separate, former is used by N = number of admins, latter is used by M = number of hosts, so the scale/performance-considerations is different. E.g. if a customer deploys Fleet Desktop on 100k+ devices, then this translates to 100k+ devices making these periodic requests, so they should be as light as possible, similar to what we already do for osquery requests.

[zwass]

Just discussed with @sharvilshah. We will go ahead and implement using the existing API for the Beta version. Let's make sure we get a separate endpoint implemented as part of getting Fleet Desktop out of Beta.

[zhumo]

de-prioritizing this in favor of our commitments for this quarter. We will revisit further into the quarter.

[noahtalerman]

Heads up @pintomi1989, this feature request was brought to feature fest on 2024-02-15 and wasn't prioritized for the current design sprint.

[spokanemac]

For more attention-grabbing, could we do something similar to what aText does with Fleet Desktop?

[lucasmrod]

@mike-j-thomas

Was taking a look at this as part of my oncall time.

Re: #5579 (comment)

Any chance you can add the red dot to these and attach them here?

• https://github.com/fleetdm/fleet/blob/main/orbit/cmd/desktop/icon_dark.png (currently used in Linux and macOS)
• https://github.com/fleetdm/fleet/blob/main/orbit/cmd/desktop/windows_app.ico (icon currently used in Windows)

PS: Not urgent at all.

[noahtalerman]

Goal

As an IT administrator, I want to be able to configure self service in Fleet so that the end user can resolve a failing issue on their company owned device.

As an end user, I want to be notified when my device isn't up to company standards so that I can resolve the issue and continue to get my job done without interruption/distraction.

Figma

Add ability to configure self service in Fleet: https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/?node-id=4357%3A170694

Related

• Parent Epic: Tell end users that they're failing policies via the menu icon. #6026
• Frontend: Expose policies on My device page #5445
• Backend: Expose policies via the GET /device/{device_id} response #4282

Tasks

1

• Add red dot to Fleet desktop taskbar icon if device is failing any policies for premium users only.
• Red badge appears if the device is failing one or more policies.
• Red badge (HEX code D66C7B) is only displayed for Fleet Premium users.
• Ask in #g-interface Slack channel if you need help grabbing the correct icon.

Notes

• Examples of a failing issue:
  • Device doesn't have the minimum supported OS (macOS, Windows, Linux)
  • Device doesn't have the supported Windows build number
  • Device doesn't have Firewall enabled (macOS, Windows, Linux)
  • Device doesn't have disk encryption enabled (macOS, Windows, Linux)

Current and future use cases

• For end user and IT admin, reducing the number of steps for the end user is important. Why?
  • IT admins may prevent end user from accessing internal tools if their device is out of compliance. The end user can't get their work done.
• For end user, ability to confirm that they resolved the issue (refetch) is important. Why?
  • User confirms that they will be able to continue work without disruption.
• For IT admin, knowing when the end user's device went out of compliance is important. Why?
  • End user can be given a warning before their access to internal tools is revoked.

[noahtalerman]

• customer-honoria: Gong snippet TODO

@pintomi1989 can you please add the Gong snippet for honoria?

[pintomi1989]

Hey @noahtalerman - I Can't seem to turn up a recorded snippet of this ask. I do have this excerpt from leadership at customer-honoria in Slack:

Wondering if I can check in on a feature request, would still be REALLY GREAT to have this fleet icon change color. Only way I would know I'm our of policy is by clicking to see the drop down menu

Here is a recording of us talking about it, but it is a reiteration of the ask to the customer: https://us-65885.app.gong.io/call?id=5893185207303179971&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A884%2C%22to%22%3A902%7D%5D

Please lmk if these things in combination work

[pboushy]

One thing I've discussed with Harry and Paul briefly is that we want to be able to inform users where they're non-compliant vs their device has some issues we recommend fixing.

Harry recommended we mark policies as "critical" if we want devices to be considered non-compliant.

Since Fleet has a concept of critical vs non-critical policies, the icon should differentiate between them.

I highly recommend that the icon use a red exclamation mark for failing critical policies vs a yellow circle for failing non-critical policies.

Unfortunately, if you just differentiate by color, you're likely to not meet WCAG 2 accessibility requirements.

[noahtalerman]

One thing I've discussed with Harry and Paul briefly is that we want to be able to inform users where they're non-compliant vs their device has some issues we recommend fixing.

Harry recommended we mark policies as "critical" if we want devices to be considered non-compliant.

Since Fleet has a concept of critical vs non-critical policies, the icon should differentiate between them.

I highly recommend that the icon use a red exclamation mark for failing critical policies vs a yellow circle for failing non-critical policies.

Unfortunately, if you just differentiate by color, you're likely to not meet WCAG 2 accessibility requirements.

Great points @pboushy! Thanks for dropping those.