How to Move Panels on Kibana5 Shared Dashboards?

Elastic Stack Kibana
1

In Kibana5, It seems not possible to drag containers in a shared dashboard (loaded in an iframe).

The new interface changed the drag and drop control to a button in the upper right corner of the container (together with "Edit" and "Remove"). Unfortunately these buttons are disabled when a dashboard is loaded in an iframe.
With this new structure, an user can Resize the panels but can't move rearranging the visualizations on a shared board (as in the previous version of Kibana).

Anyone has a clue to solve or workaround this issue?

1 Like
2

I don't think there's a solution at this time, but your problem has been noted in a Github issue about bringing back the move-by-dragging-title-area functionality: https://github.com/elastic/kibana/issues/7927

3

Hey Alexandre, I'm focused on Kibana's UI/UX right now so this is of particular interest to me. Could you tell me some more about your use case? For instance, why do people want to rearrange/resize Dashboard panels in an iframe? Is there a reason they don't want to or can't use Kibana to do this?

Thanks,
CJ

4

Hi CJ

We are working on a solution where ELK is only a part of the product, and it must be integrated with all the rest. That's why we are using Kibana in "embedded mode".

In some areas we use "fixed visualisations" but in other ones we are given the dashboard functionalities, managing the insertion and remotion of panels and saving a "personal dashboard" from our external interface. The previous version of Kibana was working perfectly for that, because we want to give the possibility to manage panel's size and position, without giving access to edit the visualisation. But with Kibana 5, we have lost this, and worse yet, people can resize panels, but not move them.

Have you any idea in your roadmap when you will release a fix for that?

From my point of view, a quick solution could be to enable to click and drag for anywhere in the top of the panel, as indicated on the issue https://github.com/elastic/kibana/issues/7927 . But maybe the best would be to give the possibility to configure what controls enable or disable, like allowing to create a dashboard with panels with "move" and "remove" buttons.

Anyway, thanks for your attention and congrats for the great software!

5

Thanks, Alexandre! This is really enlightening. I really appreciate your explanation.

CJ

6

Hi CJ

Thank you for your attention!
Have you any prevision about when you will release a patch for this issue?

thanks again

Alexandre

7

Hi Alexandre,

I can't provide any idea of when we'll ship this feature (mostly because these things are subject to change depending on evolving priorities), but I can tell you the current status of this subject. We're taking it very seriously and we're currently working on creating a better separation between the "Edit" and "View" modes of various saved objects (including Dashboards). Here's the work-in-progress PR if you're curious: https://github.com/elastic/kibana/pull/9508.

After this, we plan on implementing the kind of functionality you're asking for. Specifically, we're thinking of allowing users to Share a Dashboard and, within the Sharing interface, specify whether it's editable (and possibly to what degree). Then, if you embed a Dashboard with editability enabled, the end consumers of the embedded Dashboard will be able to move the panels around the way you describe. Does this sound like it will meet your needs?

Thanks,
CJ

2 Likes
8

Hi CJ

That's great.
As we intend to launch an Alpha version of our software pretty soon, would you have any suggestion about how to workaround the issue by now? Like using some app javascript.. Anyway let me know if there is any beta version to test. I'll appreciate to test this new features.

thanks

Alexandre

9

Hmmm... to create a workaround you would have to create a fork or branch of Kibana and implement the kind of functionality you want.

You could get started by changing this line to:

internals.setVisibleDefault(true);

This will force the entire Kibana chrome to be visible when you visit Kibana in an iframe. This solves your problem but also provides way more functionality than you probably want the end user to have. So the next step would be to update controls.js with some methods for setting and getting a "editable embedded" flag with similar methods to those that already exist.

Then, you want to update the sharing UI to add a corresponding query parameter, e.g. &editable=true, and update the flag on controls.js from within kbn_chrome.js. Now you can hide and reveal various UI components based on this property.

Hope this helps! In terms of beta testing, can you watch this Issue for progress: https://github.com/elastic/kibana/issues/9575 ? If you see us making progress on it, please ping me and remind me that you'd like to beta test. Once we have a feature branch up, you'll be able to check it out and test it at any time, and of course I would love to get your feedback at that time. Thanks!

CJ

10

Another hacky option, if all you want is panel move-ability in embedded mode, is to change this line in your kibana fork, or branch:

<span class="panel-title" title="{{::savedObj.title}}"> {{::savedObj.title}} </span>

in src/core_plugins/kibana/public/dashboard/components/panel/panel.html to this:

<span class="panel-title panel-move" title="{{::savedObj.title}}"> {{::savedObj.title}} </span>

Notice the addition of the panel-move class. Then you should be able to move the panel using the title.

1 Like
11

By the way, Alexandre, I should have mentioned that creating your own fork of Kibana is definitely an option of last resort because it carries so many risks.

Not only will keeping it in sync with the main repository be incredibly challenging, but it creates a codebase that the Kibana engineers aren't familiar with, so if you encounter bugs and need help (like here on the forums), it's possible we won't be able to help. One other problem is that using your own fork could create potential problems if you're using X-Pack, since there's no way for us to ensure that our plugins will integrate with your fork correctly. So by creating your own fork, you're assuming a large amount of risk... like I said, it's an option, but probably a last resort. :slight_smile:

CJ

13

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.