Jenkins test this

Error:

17:43:41.238: Taking screenshot "/var/lib/jenkins/workspace/elastic+kibana+pull-request+multijob-selenium/test/screenshots/failure/failure_1490031821238_dashboard tab_filters when a pie chart slice is clicked.png"
>> FAIL: chrome on any platform - kibana - dashboard app - dashboard tab - filters when a pie chart slice is clicked (1353ms)
UnknownError: [POST http://localhost:4444/wd/hub/session/f67e2d2940e0721c36ed40af112675f1/element/0.8209386374089278-45/click] unknown error: Element is not clickable at point (388, 216). Other element would receive the click: <path d="M81.89307514392158,-83.35134518093881A116.85,116.85 0 0,1 116.39530873398452,-10.298281639206838L0,0Z" class="slice" data-label="40,000" style="stroke: rgb(255, 255, 255); fill: rgb(111, 135, 216);"></path>
  (Session info: chrome=56.0.2924.87)
  (Driver info: chromedriver=2.24.417424 (c5c5ea873213ee72e3d0929b47482681555340c3),platform=Linux 4.4.0-45-generic x86_64)
  at runRequest  <node_modules/leadfoot/Session.js:88:40>
  at <node_modules/leadfoot/Session.js:109:39>
  at new Promise  <node_modules/dojo/_debug/Promise.ts:411:4>
  at ProxiedSession._post  <node_modules/leadfoot/Session.js:63:10>
  at Element._post  <node_modules/leadfoot/Element.js:23:31>
  at Element.click  <node_modules/leadfoot/Element.js:163:15>
  at <test/support/page_objects/dashboard_page.js:379:24>
  at undefined.next  <native>
  at step  <test/support/page_objects/dashboard_page.js:19:191>
  at <test/support/page_objects/dashboard_page.js:19:361>

ping @Bargs. This is a low-fruit mend it monday pr, should be a pretty easy review (famous last words).

@snide This is super minor, but I'll tag you in case you just want to give a quick glance. Before this PR we showed pinned state, and the ability to pin:

And after they are hidden (in embed mode only):

Since pinned state only matters when moving across apps.

Great call @Bargs, forgot about that Actions section. Updated.

LGTM

S3 error with jenkins.

jenkins, test this

Since pinned state only matters when moving across apps.

This is not true. Pin state matters when moving between dashboards, for example when using a markup vizualization with links to create a navigation bar.

Pinning is an important concept in the way our dashboards behave for the user (some of which are embedded in portal pages). I would really recommend making this change configurable in the Kibana advanced settings, similar to how one can configure whether filters are pinned by default. My feeling is that there are use-cases here which have not been considered.

Thanks @robacj, you are right, we did not consider that use case.

Pinning is an important concept in the way our dashboards behave for the user (some of which are embedded in portal pages).

Are your users pinning the filters themselves in embedded mode? Or do you only want those filters to show up for all dashboards in embedded mode? If the latter, it will continue to work. The underlying pin state remains the same. If you remove the &embed=true parameter you'll see the pinned state, and each pinned filter will still appear for all dashboards, no matter the mode. But you won't be able to pin, or unpin, a filter when in embedded mode, nor tell which filters are pinned and which are not.

Knowing this, would this change still pose a problem?

We have created some portal widgets that manipulate the url which is used to launch various embedded dashboards in an iframe. Those URL manipulation include setting '$state':(store:globalState) or '$state':(store:appState) depending on whether the desired starting point is pinned or not pinned. Users have the freedom to pin, unpin and add their own filters by clicking on elements of the visualization (and pin or unpin those). Users know that they can do this. How many are actually doing it??? Now that is a good question. This has long been one of the issues with "unintentional software features". Without reaching out to everyone to learn who has discovered and leveraged the features it is hard to assess the impact. However when those "features" disappear, users that find their workflow disrupted and are not happy.

I completely understand that removing the pinning options is 100% OK for some users, maybe even the majority. However for the rest of us, it would be great if the behaviour could be controlled by an advanced option... OR could be configured 'per dashboard'. I would prefer that even more as I would also like to see "pinned by default" be configurable per dashboard.

NOTE: I haven't post before this thread, so please don't interpret my commits as just complaining. You are all doing great work and I think Kibana is awesome and still getting better all of the time. However this morning this spooked me enough that I felt I needed to share my concerns.

Rob

@robacj you've brought up a great point and we highly value this kind of feedback! We definitely don't see it as complaining. I hope you join more discussions in the future!

@stacey-gammon tbh I felt a bit uncomfortable with this PR when reviewing it. I was worried there would be unintended side effects but I couldn't think of any issues at the time so I didn't want to block it just because it "didn't feel right". With this recent issue brought to light I think we should reconsider implementing it. IMO removing the pin icon in embed mode provides very little benefit at a risk of hurting some users.

@Bargs I agree with you, just left a comment on the original issue. I also vote to revert this PR.

Thank you @robacj for bringing this to our attention!