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
cjcenizal
All 30 comments
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.
uboness
on 19 Apr 2017
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.
alexfrancoeur
on 19 Apr 2017
@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.
sethyes
on 19 Apr 2017
@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.
uboness
on 19 Apr 2017
@alexfrancoeur I agree that the ability to create duplicate names is ridiculous and confusing.
sethyes
on 19 Apr 2017
@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
on 19 Apr 2017
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.
cjcenizal
on 20 Apr 2017
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.
alexfrancoeur
on 21 Apr 2017
@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:
- Difficulty linking to dashboards in a markdown widget
- 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.
stacey-gammon
on 24 Apr 2017
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
uboness
on 24 Apr 2017
+1 this would be a nice to have (Or at least a method of tiny urling
Budman17r
on 12 May 2017
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.
bwdezend
on 8 Aug 2017
+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.
CharlieTa
on 20 Sep 2017
+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.
SnchitGrover
on 4 Oct 2017
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.
jbudz
on 12 Oct 2017
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
Rumbles
on 12 Oct 2017
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.
jbudz
on 12 Oct 2017
No worries @jbudz , thanks
Rumbles
on 12 Oct 2017
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
stacey-gammon
on 13 Oct 2017
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
Rumbles
on 13 Oct 2017
@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.
ctindel
on 13 Oct 2017
CC @rodeli
cjcenizal
on 3 Nov 2017
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?
stacey-gammon
on 3 Nov 2017
@Stacey-Gammon I really like the title based look-up route, it's simple and solves a majority of use-cases.
kobelb
on 3 Nov 2017
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.
epixa
on 3 Nov 2017
I'd prefer the /dashboards?title=foo rather than /dashboardbytitle/foo, but either way solves my user's use cases.
bwdezend
on 3 Nov 2017
/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
stacey-gammon
on 3 Nov 2017
Closing this after talking with @Stacey-Gammon
cjcenizal
on 12 Mar 2018
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.
bsama
on 31 May 2018
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:
Anyone know what may be the problem here?
We are using Kibana 5.6.1.
msingh00
on 5 Feb 2019
Related issues
MaartenUreel
路
3Comments
stacey-gammon
路
3Comments
mark54g
路
3Comments
LukeMathWalker
路
3Comments
cafuego
路
3Comments
Most helpful comment
/dashboards?title=foofor the win. I like it better too, thanks for the suggestion @epixa!I'll work on cleaning up and sending out my PR