Please add test to a new file like clustersCloudService.test.js

describe('Clusters Cloud Service', () => {
    it('should redirect from main dashboard when no secured clusters', () => {

Please rewrite assertion according to majority pattern (118 versus 3 occurrences) and move into helper function because semantically related to heading assertion there, which is repeated here.

Also removes need to import url here. By the way, it can be exact match, true?

cy.location('pathname').should('eq', clustersUrl);

I intentionally took all assertions out of the helper function, because this is a one-off test, where the helper function is mainly just to abstract the API mocks and waiting.
(I almost moved everything into test, instead of keeping the mocking in a helper function, but in the end made the subjective call that the setup distracted from the assertions, so that's where I drew the line in this special case.

Is this equivalent to Bullseye layout element?

https://www.patternfly.org/v4/layouts/bullseye/design-guidelines

Use a Bullseye layout to center content, both vertically and horizontally within a container.

I tried a Bullseye at first, but required style overrides to get the spacing between the image, text, and button correct. Rather than hack in overrides, I chose to simplify. (The larger UX team recommended this look to Zhenpeng as a variation the Empty State pattern.)

Is this URL something we can determine dynamically, or do we just need to make a note to check this before each release?

We plan to redirect to a page in the 3.73 doc set once we publish the 3.73 docs. So it's not dynamic. We may want a different approach in future.

Why plan if redirects work already? #3799

@msugakov The redirect that Lynne is referring to, is a 301 redirect of that doc link to a new improved documentation page about installation, which would not exist until 3.73 is released. The redirect in the documentation means we will not have to change this hard-coded link in the product itself.

To follow up excellent improvement to add fetchingClusters and move to a pattern which supports error message if that becomes necessary, something like {content} here and if-else-if-else for assignment makes it clearer to render spinner by default (else in potential future, error message) else if no clusters AddClusterPrompt else CheckboxTable element.

I started to improve the non-empty flow, but stopped myself, so as not to set a bad example through "scope creep".

The complicated conditions imply non-obvious behavior change to render neither when fetching.

How about the following, which keeps render neither until after first fetch, but simplifies the conditions:

• It is hard to see how array length can become less than zero.
• If length is non-zero (or if you prefer, greater than zero) it seems redundant to require not fetching.

{currentClusters.length === 0 && (!fetchingClusters || pollingCount > 0) && (
    <AddClusterPrompt />
)}
{currentClusters.length !== 0 && (
    <div data-testid="clusters-table" className="h-full w-full">

After release 3.73 we can circle back to question by Dave whether no clusters unambiguously implies Cloud Service.

For the moment, no support for cluster auto-upgrade implies Cloud Service. Because it is not impossible that auto-upgrade might become supported in the future, we can follow up about how to get unambiguous indication. Besides this initial conditional rendering, it seems relevant information to render in Clusters and System Health.

https://github.com/stackrox/stackrox/blob/master/ui/apps/platform/src/services/ClustersService.ts#L100-L110

The phrase and use can admin Clusters implies a potential timing problem, because the following if statement waits until response from /v1/mypermissions request.

By "only applicable in Cloud Services version", does that mean that this situation is only ever possible in the cloud services version? Is there any way an on-prem install could return no clusters?

Related, is the ability to view clusters something that is controlled by SAC? Is it possible a user could have insufficient permissions to view clusters but still be able to do useful work, and this would cause them to get stuck on the clusters page?

...Is there any way an on-prem install could return no clusters?

While I never underestimate the ability of a user to "bork" their environment, the affordance of encouraging them to connect clusters after they have accidentally unconnected them all, is still helpful even if they are not in the Cloud Services environment. The comment is mainly to explain to folks in the future why this needed to be added at all, since the self-managed installation always adds the cluster where central is installed.

Is it possible a user could have insufficient permissions to view clusters but still be able to do useful work, and this would cause them to get stuck on the clusters page?

The check only happens on page load, so the redirect would only happen on first visit, or if the user triggered a browser refresh. They can always navigate away to do other things. There is not much useful to do until a least one cluster is connected--maybe create custom policies, or integrations--but any user without permissions wouldn't be stuck.

Another thought, I wonder if it would be worth adding some text either in the UI or on the docs page that tells the user they need to refresh the ACS UI once a cluster is added. Since Apollo caches the GQL query results, this call will continue to return 0 every time the user navigates to a new page, even after a cluster is added.

^ @lmaynard88
Is Dave's suggestion something you can add to the docs?

Yes, this can be added to the 3.73 doc.