Is there a way to handle vis._editableVis in Kibana 6.x?

(Kwan) #1

I am migrating a vis plugin from 5.x to 6.x
here is the code that can not work in kibana 6.x


// $scope.searchSource.size($scope.vis.params.numberOfRowsToFetch)
    $scope.$watch('vis._editableVis.dirty', function(nv,ov){
        if(nv == false){


In fact, _eitableVis doe not exist in 6.x at all,
what does dirty mean in here?

Two main questions:

1、Is there a way to achive same goal in 6.x as _editableVis does in kibana 5.x?
2、searchSource does not exist as $scope's method anymore, is there any way to call it or create an new one ?

(kulkarni) #2

@thomasneirynck /@ppisljar any idea here ?


(Peter Pisljar) #3

@Lynnic what is the above code trying to achieve ?

and is this code part of editor or part of actual visualization ?

the vis._editableVis.dirty indicated that there is a pending change in the editor (when set to true) which was not yet applied (the play button was not pressed).

if this code is part of visualization .... visualization really should not be checking what the editor is doing.

if the code is part of editor, then it would be good to know where in editor exactly ? but in general, the editor now stores the dirty flag directly on the vis (so $scope.vis.dirty)

again, visualization should not be checking that. when editor applies the changes visualizations render method will be called again with new data.

the other thing is the searchSource ... that is no longer available on visualization, as visualization should not be issuing requests on their own. It would be helpful to know what is the goal here, but in general, requestHandler is responsible for issuing requests to elasticsearch. If for some reason visualization really needs to query elasticsearch it can create a new searchSource by importing the SearchSourceProvider (take a look at coordinate_maps_visualization.js

(Kwan) #4

Thanks a lot for your replying @ppisljar
We now have a scenario that when changing options panel and click apply button, it will send a query request

It works fine in kibana 5.x
now we have a migration for this plugin and facing several problems

(Peter Pisljar) #5

if i understand correctly, you don't use the default editor (for building es request, like which aggregations to use) but implement your own ?

if that is the case, you should implement your own request handler. when clicking apply button your request handler will be called and you can make your request there. the response will then be passed to visualization which can use it.

  1. no need to check the dirty status
  2. no need to query from visualization

(system) #6

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