Empty index patterns page re-design

[cchaos]

Re-do of #64258

Fixes #57401

As detailed in the issue referenced above this PR addresses the empty screens of Management / Index Patterns.

Screenshots below indicate "Before" on the left, and "After" on the right

No data

The screen above also shows the case where the license may not include a specific feature.

No index patterns

---

Those are the main new screens. Below are some slight updates to current screens.

Creation Wizard

Listing page

Checklist

• i18n
• Links to the correct docs pages
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser
• This was checked for cross-browser compatibility, including a check against IE11

[cchaos]

@mattkime I think this PR is now ready to be passed on to you. There were a few NP problems I ran into with regards to snapshots that were beyond my skills. But here is a list for what is left

• Fix routes: See Empty Index Patterns page redesign #68450 for details. The empty index patterns screen is now its own route to /empty.
• Get permissions/licensing hooked in for the "Upload" option on the "No data" page so it disables correctly. Similar to how Alerts handles this.
• Hook up link to create index pattern with hidden indices from the no data screen
• Get snapshots to render for new EmptyIndexPatternPrompt component
• Get snapshots to render when the component is using the docLinks service

[mattkime]

@elasticmachine merge upstream

[elasticmachine]

merge conflict between base and head

[mattkime]

@elasticmachine merge upstream

[lukeelmers]

Added a few minor comments. My only larger question is around this environment API -- it seems to me that the ultimate use of this is to make the cards showing various ingestion options pluggable.

If that's the case, rather than having the somewhat abstract concept of an "environment" which needs to be aware of all of the different plugins which will be consuming the API, should we not instead make the API a registry of cards which are included in the UI?

Then the ML plugin would handle the permissions checks & register the "upload" card directly, and the only thing index patterns management needs to do is render cards from the registry alongside the others.

To me it seems this would be an easier API to grok and make more sense long term (assuming we plan to keep this API around and it isn't just a temporary solution)

[mattkime]

@lukeelmers

Then the ML plugin would handle the permissions checks & register the "upload" card directly, and the only thing index patterns management needs to do is render cards from the registry alongside the others.

The card is shown when the ML plugin is not present. The api is based off the api used by the home page, although with additional functionality.

I don't know what additional cards would be placed here, therefore a more complete api seems like over engineering. Its also possible that the api for discovering features will change - similar code in the home app has warning that state such. I think this is a situation where good enough is good enough.

[lukeelmers]

The card is shown when the ML plugin is not present. The api is based off the api used by the home page, although with additional functionality.

Ah, I misunderstood. Then I guess my follow-up question would be: Can this be simplified by checking the core capabilities service in the index patterns management plugin directly? Then you don't need the ml -> index pattern mgmt dependency.

In the ML plugin the check looks like this:

coreStart.application.capabilities.ml.canFindFileStructure

Is this not something we can instead check in index patterns directly, or is there something else going on that would prevent us from doing this?

[mattkime]

Can this be simplified by checking the core capabilities service in the index patterns management plugin directly? Then you don't need the ml -> index pattern mgmt dependency.

We're really performing two checks - can we use the feature? Should we be prompted to switch from OSS to basic? But we can't check the license directly because that code is in xpack. So we definitely need something registering on the index pattern management that communicates the license level. The existence of the ml plugin is being used to verify we're at least at basic.

---

Honestly, I think the amount of communication this has required indicates that something isn't very good but I'm not sure what to change. But I guess the complexity is due to oss vs xpack so thats not going away.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 1c39a74

Build metrics

@kbn/optimizer bundle module count

id	value	diff	baseline
indexPatternManagement	216	+23	193

async chunks size

id	value	diff	baseline
indexPatternManagement	806.6KB	+108.5KB	698.1KB
ml	7.9MB	+40.0B	7.9MB
total		+108.5KB

page load bundle size

id	value	diff	baseline
core	1.2MB	+116.0B	1.2MB
data	1.4MB	-15.0B	1.4MB
indexPatternManagement	135.4KB	+2.1KB	133.3KB
ml	501.5KB	+1.1KB	500.4KB
total		+3.3KB

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[lukeelmers]

The existence of the ml plugin is being used to verify we're at least at basic.

Yeah I guess what I was wondering is if performing the ML capability check for canFindFileStructure would solve for both cases, as the capability would never be present in an OSS only distribution since the ML plugin would not exist to register it. But since basic licenses could previously "expire" I guess this wouldn't work in all cases, as feature controls are not yet license-aware.

I think identifying a pattern for dealing with these scenarios will be important as I expect them to become more prevalent, however IMO it's not worth delaying this PR over it. I've added it as a topic for an upcoming shared services sync.

Code updates LGTM!

[lukeelmers]

nit: This probably doesn't have to be a required plugin, but since there's already a hard requirement on the data plugin which houses the index patterns service, it probably doesn't make a difference whether it's required or optional.