Kibana: Human readable dashboard ids

[cjcenizal]

In https://github.com/elastic/kibana/pull/9087, we migrated from repurposing dashboard titles as their IDs to using generated unique IDs. This allowed us to support dashboards with identical names, but it also means that many users who depended upon human-readable dashboard URLs are now facing a degraded experience:

• https://discuss.elastic.co/t/reverse-proxy-pattern-matching-no-longer-works-with-kibana-5/82887
• https://discuss.elastic.co/t/dashboard-names-obfuscated-in-urls-in-kibana-5/82918

Let's add functionality to allow users to opt into specifying the ID they want to use. We can begin with surfacing this in the Management Saved Object UI and then look into introducing it into the Dashboard UI as a later step, probably as some sort of hidden advanced option.

After talking with @alexfrancoeur we decided it might make sense to give users the option to specify a custom ID when saving a dashboard for the first time. We'll have to make sure to check for collisions and notify the user if there are any.

CC @Stacey-Gammon @kobelb

[uboness]

What? Why? What system lets you edit id's? This sounds like the wrong solution to potentially the wrong problem. Why are ppl depending on human readable URLs?

IDs don't change... That's part of what makes them special.

[alexfrancoeur]

I still don't understand why we allow for duplicate names in the first place. Are users really doing this? It seems like a confusing user experience whichever way you look at it. I agree with @uboness that we shouldn't be giving our users to ability to edit a unique ID. It sounds to me like we're addressing the wrong issue if this is the solution.

[sethyes]

@uboness Maybe my use-case is snowflake, but I use Markdown widgets in order to create navigation links throughout Kibana in order to create a seemless end-user experience. There are hundreds of hyperlinks in one cluster. When I was able to predict the URL, I could automate the creation of these links. Now that the links are randomly generated, I have no way to automate this link creation. I now have to manually grab the ID from every dashboard created and place that into the markdown.

[uboness]

@sethyes I understand... But this problem still doesn't justify adding the ability to edit IDs. Instead, in a different effort, we can figure out ways to help adding links to objects in kibana when writing markdown widgets. For example, have a tool to insert links... To me this will be an appropriate solution to the problem you're describing. The problem is relating to the UX of the markdown widget and how it's (admittedly often) used.

[sethyes]

@alexfrancoeur I agree that the ability to create duplicate names is ridiculous and confusing.

[cjcenizal]

@sethyes Is the ability to create duplicate names theoretically confusing, i.e. you thought about it and it seems silly, or did you actually experience a concrete moment of confusion when trying to do something? If the latter, can you tell me what you were trying to do and what happened?

[cjcenizal]

I spoke with @alexfrancoeur and we agreed that it makes sense to allow users the option of specifying a custom ID when they save a dashboard for the first time. I've updated this issue's description to reflect that.

[alexfrancoeur]

After speaking with @uboness yesterday in a bit more detail on this topic, I have some concerns with the current proposal. Before moving any further, I think we need to take a step back and look at the repercussions this might have on future implementations.

[stacey-gammon]

@sethyes I don't think this would solve your issue because you'd still have to manually open every dashboard and enter a custom id for it.

I think there are two separate issues here:

1. Difficulty linking to dashboards in a markdown widget
2. Ugly urls

For 1. I agree with @uboness that we could solve this by improving the markdown widget.

For 2. @uboness you say:

Why are ppl depending on human readable URLs?

An argument can be made for human readable URLS. Think about how facebook lets you customize your profile URL. If you visit a url often, having it be easy to remember can be helpful. We still don't have to modify the id if we wanted to allow this though.

Either way, not really a high priority IMO.

[uboness]

An argument can be made for human readable URLS. Think about how facebook lets you customize your profile URL.

Kibana != facebook. You only have one profile page in fb while in kibana you can potentially have hundreds of dashboards + hundreds of visualisations. You don't share your fb profile page as much as you share kibana dashboards - the notion of sharing is completely different - they are two entirely different things that should not be compared.

I understand that it's nice to have readable URLs... though everything comes at a cost. And I believe it can potentially cause confusion in the future and it can complicate things internally/externally (having multiple unique properties + complexity for other systems having to deal with potentially broken links).

Before we go ahead and implement something like this we needs to have a good understanding on the potential problems it can bring - and then weigh the benefits vs the downsides.

We still don't have to modify the id if we wanted to allow this though.

++... IDs should not change.

Either way, not really a high priority IMO.

++... that said, it would be nice to at least look at the UX of the markdown widget and think how to improve it

[Budman17r]

+1 this would be a nice to have (Or at least a method of tiny urling

[bwdezend]

My use case for a human readable URL comes from accessing Kibana from other systems. Email, chat, and documentation are the areas my users are already complaining about since we upgraded to Elasticsearch 5 and Kibana 5. Being unable to easily see what a link resolves slows down documentation and troubleshooting processes, and further causes issues with repeatability and usability of the service.

If there are 4 links pasted into a chat discussion about an application issue or security issue, it is much harder to troubleshoot issues in a collaborative way. Each user winds up randomly opening links until they find the link associated with the saved object being referred to.

Please allow for saved object names to transparently rewrite or redirect to the current uuid representation in kibana.

[CharlieTa]

+1 - similar use case to what is mentioned. We deploy ELK clusters into our datacenters, with each one having identical dashboards that are pre-configured. So pre-Kibana 5, it was easy to just use the name in the markdown URL's and for standalone reference to key dashboards.

Something like a dashboard object alias that we could use in a URL would be perfect.

[SnchitGrover]

+1 Even I have a similar use case where stakeholders keep asking which link is for which dashboard? Because the id differentiating the dashboards don't have a meaning. If I can change the id to name of the dashboard it would make more sense.

Currently I have to rely on bitly to shorted my link and assign a custom name to it.

[jbudz]

Allowing for a human readable name in the kibana url shortener layer seems like a more appropriate place for this to me. Bonus points for it being able to include url state and avoiding all the complexity of supporting titles and ids, and allowing for links to be updated transparently, and covering all kibana apps.

[Rumbles]

I didn't want to be able to change the ID, but since the ID is now used instead of a human readable name it makes setting the default landing page across a number of instances difficult to achieve gracefully, which is why I raised #14417

Some way to use human readable names in the URL would be beneficial in my opinion, otherwise defaultRoute is almost useless (except where you only have 1 server and you're happy to get the ID of your new dashboard and paste it in to the kibana.yml) unless you just want to point people at just visualisations or dashboards, you can't easily point the user to a particular dashboard as far as I know

[jbudz]

Got it, sorry about that @Rumbles. I'm going to edit the title here to be problem instead of solution oriented - I'm hoping we can merge these discussions because the end goal is the same.

[Rumbles]

No worries @jbudz , thanks

[stacey-gammon]

cc @elastic/kibana-sharing, lets discuss this issue at our next meeting, post Berlin. It appears this is becoming more of an issue for folks and it might be time we take another stab at finding a good solution. cc @ctindel

[Rumbles]

for my use case, aliasing the human readable name to the ID for use as a redirect seems like a nice solution

it doesn't matter what page I end up on, as long as defaultRoute can be set to a static name, you just have to consider people might create clashing names and handle it gracefully perhaps by blocking it on creation

[ctindel]

@Rumbles

Or noticing that there are > 1 dashboards with the same human readable name and taking them to a prepopulated dashboard search showing them all the options.

https://github.com/elastic/kibana/issues/14461

[cjcenizal]

CC @rodeli

[stacey-gammon]

I think I'm on board with the proposal to introduce a new route that searched by title, and redirected the user to the dashboard if a single dashboard with that title was found, or the search page with a filter applied if not, or if multiple dashboards with that title were found.

E.g.:

Similar to how facebook has your standard url - https://www.facebook.com/mycustomurl but you can also load it by id https://www.facebook.com/profile.php?id=24353623.

What I'm proposing is reversed - the default url uses the id, and the lesser used one uses the title, but this helps us get around potential duplicate titles.

We might be able to also introduce the ability to give a custom id when first creating a dashboard, but I believe there are security concerns with that, once object level security is implemented. e.g. I'm a user and I try to create a dashboard with a custom id of 'marketing-dashboard', but get a conflict because another private dashboard, that I'm not allowed to see, already exists with that custom id. Now I have knowledge of the existence of a dashboard that I shouldn't know exists. Though I need to refresh my knowledge of the security concerns around it to be sure I'm getting that all right.

But adding in a new route is a pretty simple solution (I have a PR I could mail out tomorrow) that might cover most use cases?

[kobelb]

@Stacey-Gammon I really like the title based look-up route, it's simple and solves a majority of use-cases.

[epixa]

I like the title lookup thing as well, though rather than adding an entirely new route, I'd recommend just adding "title" as a query parameter to /dashboards. The idea being that this feature isn't about loading a single dashboard, it's about a special filtering behavior on dashboards as a whole that automatically redirects you in the event that there is only a single dashboard. Describing the feature in this way helps explain why you end up in a dashboard list when multiple dashboards match.

[bwdezend]

I'd prefer the /dashboards?title=foo rather than /dashboardbytitle/foo, but either way solves my user's use cases.

[stacey-gammon]

/dashboards?title=foo for the win. I like it better too, thanks for the suggestion @epixa!

I'll work on cleaning up and sending out my PR

[cjcenizal]

Closing this after talking with @Stacey-Gammon

[bsama]

This worked for me. I created a dashboard from the kibana UI and then from the saved objects, i exported the dashboard object to my mac. when I expanded the JSON it had the _id with a random ID of the dashboard. I changed it to the name I wanted for the dashboard and imported JSON back to kibana.

[msingh00]

i used the technique above (export, change id, import) to generate human readable id and therefore a more user friendly URL. Works fine..sometimes. Occasionally however, i still get the error "Could not locate that index-pattern (id: ), click here to re-create it". When this happens, i either have to clear the cache and re-launch chrome, or open an incognito window. Using an incognito window always works without issues.
Anyone know what may be the problem here?
We are using Kibana 5.6.1.