Hosting screen: respect the reset state for filters

[oandregal]

Quick summary

After the user has reset the filter states, changing the view sets "All sites" again.

Steps to reproduce

I provide a video to reproduce:

Gravacao.do.ecra.2024-08-22.as.13.28.44.mov

What you expected to happen

The filters should be reset.

What actually happened

The filters were set again.

Impact

All

Available workarounds?

There is no user impact

If the above answer is "Yes...", outline the workaround.

No response

Platform (Simple and/or Atomic)

No response

Logs or notes

No response

[davemart-in]

Thanks for reporting this @oandregal! This seems straightforward. I moved it to "Ready for Dev"

[Addison-Stavlo]

I think having "All sites" listed as the filter by default is by design here. cc @lucasmendes-design

There is currently no indication on the status column header that it can be filtered (I think the original had a dropdown/popover for choosing the filter setting, that design iterations ended up having us remove?), unlike other columns where we do show indications (like sorting for example):

Having the default filter of "all sites" set makes the filters easily discoverable. As this icon by itself is not something our users would easily identify as where to filter by status:

I think if we want to remove the default filter for "All sites" that shows up, we should apply some other design (such as to the column header) to better indicate the availability of (and even apply) filtering.

[mmtr]

I think having "All sites" listed as the filter by default is by design here

Can we then make these changes?

• If filters are in their default state, "Reset filters" and "Reset status" should be disabled/greyed out

• If filters are in their default state, and a site is selected, the filters icon in the left sidebar shouldn't have any number:

Expected	Wrong

• If filters are NOT in their default state, when clicking on "Reset filters", the label next to the filters icon should say "Status is All sites":

Expected	Wrong

[oandregal]

Just noting that there's this PR to update the DataViews version in use #93503 It looks like it may be merged this afternoon or tomorrow morning. 🤞

This is a bit unusual for me, but I'd perhaps suggest fixing this issue after 93503 is merged if this is a big change. 93503 is a difficult PR that has been 3 weeks in the works, and it'd be good to avoid conflicts, complex rebases, etc.

[Addison-Stavlo]

Can we then make these changes?

These are logical and seem like an option we could move forward with.

I think the alternative approach would be:

• Make the filters reset as they should (default state = no filters, not 'all sites')
• We go back to having the dropdown/popover that appears from the "status" header. Whether it is the core one, or with slightly different styles to better match here.

Noting for context on that second note. In core DataViews, when a column allows filtering, there is/was a dropdown on the column header to select the filter you want for that column. Our designers didn't like the design for this and we sort of overrode it by hacking. The visible "status" columns is not set up for filtering, and in place we added an invisible status column that enables the filters to show up in the other filtering UI. IIRC this was all done to avoid having the dropdown from the column header, and I think why we make filters more discoverable by the "all sites" default state.

So the other option is to re-think that design conflict, and show the dropdown from the header as core does or in a similar way. In which case we could just make the default state no filters at all, as it probably should be.

I'd perhaps suggest fixing this issue after 93503 is merged

👍 Thanks for mentioning that.

[Addison-Stavlo]

Given the dataViews refactor has re-added the popovers anyways:

We may as well fix the hack hiding the filtering from here, and just default the filter to none.

[Addison-Stavlo]

#94253 should resolve this.