Kibana version: 5.4.0 BC2
Elasticsearch version: 5.4.0 BC2
Description of the problem including expected versus actual behavior: A recent improvement in Kibana (I can't find the PR but I think it was in one of the 5.x releases) added code to auto-select a default index pattern if there are index patterns defined but no default set. This feature seems to have regressed, at least when xpack is installed:

Steps to reproduce:
./scripts/import_dashboards -user elastic -pass changeme -url https://staging.elastic.co/5.4.0-a48f2a0a/downloads/beats/beats-dashboards/beats-dashboards-5.4.0.zip. I think this step is optional, but mentioning what I didFWIW, this works with master without xpack installed. So it's either related to xpack or specific to the 5.4 release.
I believe it only selects a default index pattern if there is only one index pattern available. Since ml also installs index patterns, that is why you're seeing this when xpack is installed.
I'm pretty sure it only sets an index pattern as the default as you create it in the UI if there is not already one set as the default.
If you create an index pattern (or multiple index patterns) by writing it to the .kibana index Kibana will not set it to the default automatically.
I think these are the cases;
Case | Action | Result
------|--------|--------
A | There are no index patterns and you try to navigate to Discover, Visualize, Dashboard | You get that error banner
B | There are no index patterns and you create one in the UI | It becomes the default index pattern
C | There are index patterns created outside of the UI (loading beats index patterns, viz, etc) | Nothing is set to the default and you get that error banner (the user should decide what is the default)
D | ML in X-Pack was creating index patterns outside of the UI and it was setting one of them to the default | ML shouldn't do that. I think they stopped already. So you would see that error until you set an index pattern to be the default, or create a new index pattern and it will become the default
We changed it recently so that it would select an index pattern as the default automatically if there was only one in the system. I think it was in 5.3
Found the PR: https://github.com/elastic/kibana/pull/9679
We could update this functionality to be a little more intelligent in how it selects the default index pattern. We could de-prioritize internal indices (those that begin with a .) in favor of others, so if you only have one non-internal index pattern, we'll select it as the default.
Thoughts?
Thanks for looking into this. My issue with the current implementation is that if you want to go straight to the dashboards, and don't care much about Discover (which is usually the case for Metricbeat), you don't need the index pattern. So it feels like an unnecessary distraction to the user.
I like the solution proposed by @epixa for the short/medium term, but feel free to merge this ticket in #7624 if that makes sense. CC @Bargs
I wonder if in the short term we should just select a (non-internal) default regardless of the number of index patterns that exist. If there are more than one, just pick the first one in the list. Maybe display a notification that says "hey we just made x-* your default index pattern because you didn't have one, you can change this in Management -> Index Patterns".
As kibana exists today, having no default index pattern is basically an invalid state the user should never be in and I'd think a randomly selected index pattern is better than none at all.
Most helpful comment
I wonder if in the short term we should just select a (non-internal) default regardless of the number of index patterns that exist. If there are more than one, just pick the first one in the list. Maybe display a notification that says "hey we just made x-* your default index pattern because you didn't have one, you can change this in Management -> Index Patterns".
As kibana exists today, having no default index pattern is basically an invalid state the user should never be in and I'd think a randomly selected index pattern is better than none at all.