You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/ROOT/pages/api-changelog.adoc
+43-25Lines changed: 43 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,36 @@
1
-
= Visual Embed changelog
1
+
= Visual Embed SDK changelog
2
2
:toc: true
3
-
:toclevels: 1
3
+
:toclevels: 2
4
4
5
-
:page-title: Changelog
5
+
:page-title: Visual Embed SDK changelog
6
6
:page-pageid: embed-sdk-changelog
7
-
:page-description: Changes to the SDK and APIs
7
+
:page-description: Changelog for the Visual Embed SDK
8
8
9
-
This changelog lists only the changes introduced in the Visual Embed SDK. For information about new features and enhancements available for embedded analytics, see xref:whats-new.adoc[What's New].
9
+
This page documents the changes introduced in each release of the Visual Embed SDK. For information about the REST API v2.0 changes, see the xref:rest-apiv2-changelog.adoc[REST API v2.0 changelog].
10
+
11
+
12
+
== Version 1.50.x, July 2026
13
+
14
+
[width="100%", cols="1,4"]
15
+
|====
16
+
|[tag greenBackground]#NEW FEATURE# a|
17
+
18
+
[discrete]
19
+
===== SpotterViz embed customization
20
+
The Visual Embed SDK 1.50.0 introduces the `SpotterVizConfig` interface and `SpotterVizStarterPrompt` interface to allow embed developers to customize the SpotterViz panel on embedded Liveboards and full-application embeds.
21
+
22
+
A new `SpotterVizConfig` interface is available on `LiveboardViewConfig` and `AppViewConfig` for the `spotterViz` object. This object provides branding customization controls for customizing the SpotterViz panel experience.
23
+
24
+
To customize app interactions, visibility of the UI elements, and style and appearance of the SpotterViz panel, the SDK also introduces CSS variables, action IDs, and embed and host event identifiers. For more information, see xref:embed-spotterViz.adoc[SpotterViz in embedded Liveboards].
25
+
26
+
|[tag greenBackground]#NEW FEATURE# a|
27
+
28
+
[discrete]
29
+
===== Home page customization in full application embedding
30
+
For full application embedding, ThoughtSpot provides a focused and streamlined home page experience. To enable this feature, use the `HomePage.Focused` option with the `homePage` attribute in the `discoveryExperience` object.
31
+
32
+
For more information, see xref:full-app-customize.adoc[Customize full application embedding].
33
+
|====
10
34
11
35
== Version 1.49.x, June 2026
12
36
@@ -30,42 +54,36 @@ The `visualOverrides` object provides the following customization controls to mo
30
54
* `columns` property for column visibility, text wrapping, conditional formatting, and column summary in tables.
31
55
32
56
For more information, see xref:viz-overrides.adoc[Visualization overrides].
33
-
34
-
//|[tag greenBackground]#NEW FEATURE# a|
35
-
//[discrete]
36
-
//===== New charts library
37
-
38
-
//The SDK introduces the `newChartsLibrary` parameter to enable the new Muze charting library in Liveboard and full application embedding.
39
-
40
57
|[tag greenBackground]#NEW FEATURE# a|
58
+
41
59
[discrete]
42
60
===== Liveboard browser cache refresh
61
+
For embedded Liveboards, the SDK provides `enableLiveboardDataCache` to clear browser cache and fetch new data for the visualizations on the Liveboard.
43
62
44
-
The SDK introduces the following event IDs and action ID to support programmatic and user-triggered browser cache refresh for the Liveboard ChartViz containers. These APIs require `enableLiveboardDataCache` to be enabled in your embed configuration.
45
-
46
-
Events::
63
+
The SDK also provides the following events and action ID to programmatically trigger cache refresh and control the visibility of the **Refresh** button.
47
64
48
65
* `EmbedEvent.RefreshLiveboardBrowserCache` +
49
-
Emitted when a user clicks the *Refresh* button in the Liveboard header to clear the browser cache.
50
-
66
+
Emitted when the Liveboard browser cache is refreshed.
51
67
* `HostEvent.RefreshLiveboardBrowserCache` +
52
-
Allows the host application to programmatically trigger a browser cache refresh for all visualization containers on the embedded Liveboard.
53
-
54
-
New action ID::
55
-
68
+
Trigger a manual cache refresh from the host application.
56
69
* `Action.RefreshLiveboardBrowserCache` +
57
-
Action ID to control the visibility of the *Refresh* button that clears the browser cache and fetches new data for Liveboard ChartViz containers.
70
+
Action ID to show or hide the cache refresh button.
71
+
72
+
For more information, see xref:embed-pinboard.adoc#liveboard-data-cache[Enable Liveboard refresh].
58
73
59
74
|[tag greenBackground]#NEW FEATURE# a|
60
75
[discrete]
61
76
===== Spotter file upload
62
-
The SDK introduces the following configuration parameters in `SpotterChatViewConfig` to enable and control file uploads in the embedded Spotter chat interface.
77
+
The SDK introduces the following configuration parameters in `SpotterChatConfig` object to enable and control file uploads in the embedded Spotter chat interface.
63
78
64
79
* `spotterFileUploadEnabled` +
65
80
When set to `true`, enables the file upload feature in the Spotter chat panel.
66
81
67
82
* `spotterFileUploadFileTypes` +
68
-
Restricts the file types allowed for upload in the Spotter chat panel. Accepts a `SpotterFileUploadFileTypes` object.
83
+
Restricts the file types allowed for upload in the Spotter chat panel.
84
+
85
+
For more information, see xref:embed-spotter.adoc#fileUpload[Allowing file uploads in Spotter chats].
86
+
69
87
|====
70
88
71
89
@@ -1846,4 +1864,4 @@ Users with edit permissions can view and access the *Edit* action. The *Download
1846
1864
1847
1865
When a user accesses the embedded application from a web browser that has third-party cookies disabled, the Visual Embed SDK emits the `NoCookieAccess` event to notify the developer. Cookies are disabled by default in Safari. Users can enable third-party cookies in Safari’s Preferences setting page or use another web browser.
1848
1866
To know how to enable this setting by default on Safari for a ThoughtSpot embedded instance, contact ThoughtSpot Support.
Copy file name to clipboardExpand all lines: modules/ROOT/pages/api-user-management.adoc
+37-6Lines changed: 37 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ While you can delete users, it is preferable to deactivate a user, which maintai
16
16
17
17
When configuring xref:configure-saml.adoc[SAML SSO] in ThoughtSpot UI, you can select the *Automatically add SAML users to ThoughtSpot upon first authentication* option, which will use the values in the SAML assertion to create a user if they do not already exist on ThoughtSpot. ThoughtSpot can also add users to groups sent within the SAML assertion. To enable and configure the SAML group attributes, contact your ThoughtSpot team.
18
18
19
-
By default, ThoughtSpot sends e-mail messages to a new user and enables onboarding workflows when they log in for the first time, even when you are embedding ThoughtSpot content. To alter this behavior at a system-wide level, you need to xref:customize-email-settings.adoc[Customize the onboarding settings].
19
+
By default, ThoughtSpot sends e-mail messages to a new user and enables onboarding workflows when they log in for the first time, even when you are embedding ThoughtSpot content. To alter this behavior at a system-wide level, you need to xref:customize-email-settings.adoc[Customize the onboarding settings].
20
20
The user update API also allows setting onboarding experience values for an individual user. If you need to modify the default behavior beyond the available UI options, contact your ThoughtSpot team.
ThoughtSpot is gradually migrating its user to link:https://docs.thoughtspot.com/cloud/latest/okta-iam[Identity and Access Management v2 (IAMv2), window=_blank] to provide a more secure login and authentication experience through internal authentication with Okta. The following are some of the important points to note with this upgrade:
111
+
ThoughtSpot is gradually migrating its users to link:https://docs.thoughtspot.com/cloud/latest/okta-iam[Identity and Access Management v2 (IAMv2), window=_blank] to provide a more secure login and authentication experience through internal authentication with Okta. The following are some of the important points to note with this upgrade:
112
112
113
-
* The `email` attribute is mandatory when creating a user in ThoughtSpot Okta. ThoughtSpot recommends users to provide a valid email address during the user creation.
113
+
* The `email` attribute is mandatory when creating a user in ThoughtSpot Okta. ThoughtSpot recommends that users provide a valid email address during user creation.
114
114
* You must set a password during user creation if you do not want to trigger an activation email.
115
115
* The default value for `usertype` will be `OIDC_USER`.
116
116
@@ -127,6 +127,26 @@ To update user details:
127
127
* +++<a href="{{navprefix}}/restV2-playground?apiResourceId=http%2Fapi-endpoints%2Fusers%2Fupdate-user">POST /api/rest/2.0/users/{user_identifier}/update</a>+++ (Rest API v2)
128
128
* xref:user-api.adoc#update-user[PUT /tspublic/v1/user/{userid}] (Rest API v1)
129
129
130
+
[NOTE]
131
+
====
132
+
Updating the username of an SSO user, `account_type` set to `SAML_USER` or `OIDC_USER`, requires changes in both the IdP and ThoughtSpot.
133
+
134
+
If you rename an SSO user through the REST API and that user then logs in through the IdP:
135
+
136
+
* If Just-in-Time (JIT) provisioning is enabled, ThoughtSpot creates a new duplicate account. The duplicate account does not inherit the original user's content, groups, or permissions.
137
+
* If JIT provisioning is disabled, the user cannot log in.
138
+
139
+
To safely update the username of an SSO user:
140
+
141
+
. Update the username in your IdP.
142
+
. Before the user logs in again, update the username in ThoughtSpot to match the new value using the REST API or Admin UI.
143
+
144
+
Both updates must be complete before the user's next SSO login.
145
+
The order of the two steps can be reversed — you may update ThoughtSpot first and the IdP second — provided the user does not log in during the interval between the two changes.
146
+
147
+
For SSO users, ThoughtSpot derives email address and display name directly from the IdP. Update these attributes in your IdP only.
148
+
ThoughtSpot automatically reflects the new values when the user next logs in through SSO.
149
+
Do not use the REST API or the Admin UI to update the email address or display name of an SSO user.
130
150
131
151
[NOTE]
132
152
====
@@ -191,7 +211,7 @@ To remove a user from a group, use the update group REST v2 endpoint, or the fol
removes a list of users] from many groups at once.
214
+
removes a list of users from many groups at once.
195
215
196
216
== Access control (sharing)
197
217
Access to objects is determined by content *shared* directly to the user or the groups they belong to. It is easier to manage and audit sharing through groups rather than object sharing at the individual user level.
@@ -215,6 +235,17 @@ ThoughtSpot also has a default group called `All`. When you create new users in
215
235
====
216
236
217
237
== Roles
218
-
If Role-Based Access Control (RBAC) is enabled on your instance, administrators can define Role privileges and assign these to users via Groups.
238
+
If Role-Based Access Control (RBAC) is enabled on your instance, administrators can define role privileges and assign them to users via groups. Roles are always scoped to an Org; a role created in one Org cannot be assigned in another.
239
+
240
+
=== Assign roles to groups via REST API
241
+
When creating or updating a group using the REST API v2 endpoints, use the `role_identifiers` parameter to assign one or more roles to the group. The parameter accepts an array of role GUIDs or role names. For more information, see:
242
+
243
+
* link:{{navprefix}}/restV2-playground?apiResourceId=http%2Fapi-endpoints%2Fgroups%2Fcreate-user-group[`POST /api/rest/2.0/groups/create`]: include `role_identifiers` in the request body.
244
+
* link:{{navprefix}}/restV2-playground?apiResourceId=http%2Fapi-endpoints%2Fgroups%2Fupdate-user-group[`POST /api/rest/2.0/groups/{group_identifier}/update`]: include `role_identifiers` to add roles to an existing group.
245
+
246
+
[NOTE]
247
+
====
248
+
Roles must be available before they can be assigned. Use the xref:roles-api.adoc[Roles API] to create roles programmatically before calling the group create or update endpoints.
249
+
====
219
250
220
-
For more information, see xref:roles.adoc[Role-based access control] and link:https://docs.thoughtspot.com/cloud/latest/rbac[ThoughtSpot Product documentation, window=_blank].
251
+
For a complete list of available privileges and role categories, see xref:roles.adoc[Role-based access control].
0 commit comments