sumith - #dev-help I am trying to access Spotte...
# dev-help
s
#1143209464875462756 I am trying to access Spotter button on liveboard using CSS / JS, but due to CORS error, I am not able to do that. After accessing that, I might need that button to hide/disable conditionally. I have checked Embed HostEvents but didn't find anything useful on that as well. Any thoughts on this?
a
message has been deleted
s
Solution: You won’t be able to reliably access the Spotter button inside the embedded Liveboard with host-page CSS/JS because the embed runs in an iframe, so browser same-origin rules block DOM access. The supported way is to control the built-in UI through the SDK action APIs, not by querying the button element directly. For the Spotter button on a Liveboard, the official action is
Action.AskAi
, described as the Spotter action in Liveboard, full app, and Spotter embed. You can hide it with
hiddenActions
or keep it visible but non-clickable with
disabledActions
. The docs for Liveboard customization explicitly say to use
hiddenActions
,
disabledActions
, or
visibleActions
for menu/UI actions. If you need it conditional, decide the condition in your app before creating/rendering the embed, then pass the appropriate config. Source docs do not show a HostEvent for toggling this after render.
Copy code
javascript
import {
  init,
  AuthType,
  LiveboardEmbed,
  Action,
} from '@thoughtspot/visual-embed-sdk';

const shouldHideSpotter = true;      // your app condition
const shouldDisableSpotter = false;  // your app condition

init({
  thoughtSpotHost: 'https://your-ts-host',
  authType: AuthType.None,
});

const embed = new LiveboardEmbed(
  document.getElementById('ts-embed'),
  {
    liveboardId: 'YOUR_LIVEBOARD_ID',
    frameParams: { width: '100%', height: '800px' },

    hiddenActions: shouldHideSpotter ? [Action.AskAi] : ,
    disabledActions: shouldDisableSpotter ? [Action.AskAi] : ,
  }
);

embed.render;
If you want an allow-list approach instead, use
visibleActions
and simply omit
Action.AskAi
. The SDK docs define
visibleActions
as an allow-list, so anything not included stays hidden. Suggestions: - Don’t use DOM selectors or injected CSS against the iframe contents; that’s exactly where the CORS/same-origin issue comes from, and it’s not the supported extension point.
- If your condition changes at runtime, the documented approach from the results is configuration-driven at embed creation time. If you need the state to change later, the safe pattern is to destroy/recreate the embed with a different
hiddenActions
/
disabledActions
config rather than trying to mutate iframe DOM. - If your actual target is not the main Spotter/Ask AI button but a Spotter UI control inside Spotter itself, there are additional Spotter-specific
Action
values such as
PreviewDataSpotter
,
ResetSpotterChat
,
SpotterFeedback
,
EditPreviousPrompt
, and
DeletePreviousPrompt
. Those are documented for Spotter UI controls, but they are different from the Liveboard Spotter entry point. - I couldn’t find anything in the official ThoughtSpot documentation for a HostEvent that conditionally hides/disables the Liveboard Spotter button after render. The official docs returned action-based configuration for this use case instead. Docs: - Liveboard customization with
hiddenActions
,
disabledActions
, `visibleActions`: https://developers.thoughtspot.com/docs/embed-liveboard#_customize_liveboard_view -
Action
enum reference, including `Action.AskAi`: https://developers.thoughtspot.com/docs/Enumeration_Action - Embed action patterns/example: https://github.com/thoughtspot/developer-examples/blob/main/visual-embed/actions/README.md
j
did that help ? if you are trying to access a dom element from outside the iframe its not possible
you can use the action suggested by @spotter-code , or use custom css with rules unstable as a last option
s
Solution: Yes — that’s the right direction. You should not try to access the Spotter button inside the embedded iframe using host-page CSS/JS. The iframe boundary is why you hit the CORS/cross-origin restriction. The supported approach is: 1. Use SDK action control first -
Action.AskAi
is the official action for Spotter on Liveboards. - Use: -
hiddenActions: [Action.AskAi]
to remove it -
disabledActions: [Action.AskAi]
to keep it visible but non-clickable
Copy code
js
import {
  init,
  AuthType,
  LiveboardEmbed,
  Action,
} from "@thoughtspot/visual-embed-sdk";

init({
  thoughtSpotHost: "https://your-thoughtspot-host",
  authType: AuthType.None,
});

const shouldHideSpotter = true;
const shouldDisableSpotter = false;

const liveboard = new LiveboardEmbed("#ts-embed", {
  liveboardId: "your-liveboard-id",
  hiddenActions: shouldHideSpotter ? [Action.AskAi] : ,
  disabledActions: shouldDisableSpotter ? [Action.AskAi] : ,
  disabledActionReason: shouldDisableSpotter
    ? "Spotter is not available for this user"
    : undefined,
});

liveboard.render;
Also relevant: if Spotter is enabled on your instance, it can appear as the default primary action on Liveboard visualizations. You can replace that primary button with another supported action using
primaryAction
. If you do that, the default action is moved into the
...
menu rather than removed. 2. Use
rules_UNSTABLE
only as a fallback
- Official docs do allow
rules_UNSTABLE
for unsupported UI-level overrides in some cases. - But it is intentionally unstable, so selectors can break across releases. - Use it only if
Action.AskAi
does not cover your exact UI case. Important: I could not find an official HostEvent specifically for conditionally toggling the Spotter Liveboard button after render. The documented control here is through
hiddenActions
/
disabledActions
, not HostEvents. --- Suggestions:
- If your logic is role-based or entitlement-based, decide the state before creating the
LiveboardEmbed
, then pass
hiddenActions
or
disabledActions
at construction time. - If the condition changes at runtime, the safest pattern is usually to re-render the embed with a different config rather than trying to reach into iframe DOM. - If your goal is to change the button’s appearance rather than behavior, use supported customization options first. The official CSS variable list does not include a dedicated “hide Spotter button” variable. -
rules_UNSTABLE
is documented as a workaround path for certain unsupported elements, so your statement is accurate: it’s a last resort, not the recommended primary solution. --- Docs: - Action enum / `Action.AskAi`: https://developers.thoughtspot.com/docs/Enumeration_Action - Show, hide, disable actions: https://developers.thoughtspot.com/docs/actions - Override default primary action on Liveboards: https://developers.thoughtspot.com/docs/action-config#_override_default_primary_actions - CSS variables reference: https://developers.thoughtspot.com/docs/css-variables-reference - Spotter embed customization: https://developers.thoughtspot.com/docs/embed-spotter