Adding additional dimensions to the Scatter Map widget tooltip
Adding additional dimensions to the Scatter Map widget tooltip Additional dimensions can be added to the hover tooltip of the Scatter Map widget type, beyond the default limit of three, to include more information from other dimensions about a location in a Scatter Map widget. This can be accomplished by using a combination of the widget's before query event to add additional dimension data for the hover tooltips and the before datapoint tooltip event to incorporate these dimensions into the tooltip. This method of modifying the query using the "beforequery" event can also be applied to all other widget types // Add extra parameters to be used in tooltips by modifying query widget.on('beforequery', function (se, ev) { // Initial number of widget metadata panels excluding filter panel widget.initialPanelSizeExcludingFilterPanel = ev.query.metadata.filter((panel) => { return panel.panel !== "scope" }).length; // Extra dimensions to show in tooltip, should return a single result, include as many as needed, just add to array // Jaql Objects can be copied from other widgets from the prism.activeWidget.metadata.panels via the browser console // Modify JAQL as needed, title of JAQL is used in tooltip and can be modified to any string widget.extraDimensionJAQL = [ { "jaql": { "table": "Category", "column": "Category ID", "dim": "[Category.Category ID]", "datatype": "numeric", "merged": true, "agg": "count", "title": "Unique Category ID" } }, { "jaql": { "table": "Country", "column": "Country ID", "dim": "[Country.Country ID]", "datatype": "numeric", "merged": true, "agg": "count", "title": "Unique Country ID" } }, ] // Add to default widget query the extra dimensions to be used in tooltips ev.query.metadata = ev.query.metadata.concat(widget.extraDimensionJAQL) }); // Add extra dimensions added with beforequery object to ScatterMap tooltip widget.on("beforedatapointtooltip", (event, params) => { // Convert query results to include only the additional dimensions, and formatted for tooltip template var onlyAdditionalDimensions = widget.queryResult.$$rows.map((withoutDefaultDimensionOnlyAdditional) => { // Remove the default dimensions, first part of row result array var withoutDefaultDimensionOnlyAdditional = withoutDefaultDimensionOnlyAdditional.slice(widget.initialPanelSizeExcludingFilterPanel) // Format for tooltip template, include title from JAQL var extraDimensionObj = withoutDefaultDimensionOnlyAdditional.map((extraDimensionValue, index) => { // Use extraDimensionJAQL for label in tooltip return { "text": extraDimensionValue.text, "title": widget.extraDimensionJAQL[index].jaql.title } }) return extraDimensionObj }); // Object to store extra dimensions params.context.marker.extraDimension = {}; // Use matching queryIndex for tooltip of additional dimensions params.context.marker.extraDimension.arr = onlyAdditionalDimensions[params.context.marker.queryIndex]; // Template for tooltip, modify as needed params.template = ` <div class='geo-text'>{{ model.marker.name }}</div> <div class='measure-holder' data-ng-if='model.measuresMetadata.sizeTitle'> <div class='measure-title slf-text-secondary'>{{ model.measuresMetadata.sizeTitle }}:</div> <div class='measure-value'>{{ model.marker.sizeObj.text }}</div> </div> <div class='measure-holder' data-ng-if='model.measuresMetadata.colorTitle'> <div class='measure-title slf-text-secondary'>{{ model.measuresMetadata.colorTitle }}:</div> <div class='measure-value'>{{ model.marker.colorObj.text }}</div> </div> <div class='measure-holder details-measure-holder' data-ng-if='model.measuresMetadata.detailsTitle'> <div class='measure-title slf-text-secondary'>{{ model.measuresMetadata.detailsTitle }}:</div> <div class='measure-value' data-ng-if="!model.marker.detailsObj.arr">{{ model.marker.detailsObj.text }}</div> <div class="details-wait" data-ng-if="model.marker.detailsObj.pendingDetails"></div> <div data-ng-if="model.marker.detailsObj.arr"> <div class="details-value" data-ng-repeat="a in model.marker.detailsObj.arr">{{a.text}}</div> <div class="details-counter" data-ng-if="model.marker.detailsObj.hasMore"> <div class="details-counter">...</div> <div class="details-counter"> {{'smap.ttip.firstres'|translate:(args={count:model.marker.detailsObj.arr.length})}}</div> </div> </div> </div> <div data-ng-if="model.marker.extraDimension.arr"> <div data-ng-if='model.measuresMetadata.colorTitle'> <div class='measure-holder' data-ng-repeat="a in model.marker.extraDimension.arr"> <div class='measure-title slf-text-secondary'>{{a.title}}:</div> <div class="measure-value extra-dimension-value">{{a.text}}</div> </div> </div> </div>`; }); The JAQL can be changed to any valid JAQL object, and the tooltip template can also be further modified.Branding/White Labeling with Sisense
What is Branding? Branding or white-labeling is a way to alter the visual part of an application to match your application's visual style. Sisense provides a list of options for rebranding the visual style of GUI, emails, and so on. Sisense provides the following branding options, including: Look and Feel Email strings customization Email logos customization Basic general branding Look and Feel Look and feel allows users to quickly and easily change things like font, panel color, text color, etc. For more information, read through Sisense's documentation on Customizing the Sisense User Interface (https://documentation.sisense.com/docs/customizing-the-sisense-user-interface). Email Strings Customization Sisense has a list of predefined email templates that are used to send reports on dashboards, builds, and so on. In some cases, the text in those emails can be customized. For example, users have the option to replace Sisense with their custom company name. Text(strings) used in email templates are translated to multiple languages and are saved locally. With this information, users can then alter the text in translation files to change the text in email reports. Translation files for emails can be found under the following path: Linux: /opt/sisense/storage/translations/{Language}/email-templates.js (Or {Server}/app/explore/files/translations/en-US/email-templates.js using Web File Manager) Windows: C:\Program Files\Sisense\app\translations\{Language}/email-templates.js In most cases, English is used for emails, therefore, the folder we need will be en-US. This file contains all the strings that are used in email reports in the following format: {Email type}: { {token}: '{String}', {token}: '{String}' } Where token is the variable that should not be removed from the file, new tokens should not be added as well. String is the actual text that will appear in our email, and is therefore the only thing that can be edited. Here is an example of how to change one of the strings under the test_email type: Once changes are complete, the Galaxy service/pod should be restarted (Restart Sisense.Galaxy service in Windows): This will trigger a test email where we will see the changes in the email body text. Before: After: Email Logos Customization Logos used in email reports can be changed by replacing the default logo files with custom ones. Default images are stored here: Linux: /opt/sisense/storage/emails/images/ (Or {Server}/app/explore/files/emails/images/ using Web File Manager) Windows: C:\Program Files\Sisense\app\galaxy-service\src\features\emails\templates\images\ Note, that if a custom location for a template is specified, the default images and templates will be ignored. The images are mapped using a name, therefore in order to replace the image, the new file should have an identical name. Below is an example of how this works. Below, is the same default recovery password email referenced earlier in the article: Let us replace recover-password.png file with a new one and restart the galaxy pod: Below is the result: Basic General Branding Sisense has a list of branding parameters that can be further adjusted to white label your application. It can be located and changed in 2 ways: Using REST API: Using Configuration Manager ({Host}/app/configuration/system in Linux or Localhost:3030 in Windows): From here, we can change the logos, strings, and toggle some parameters on or off. Saving should prompt relevant services to restart automatically. Pay additional importance to the "Emails Templates Directory" parameter as it will allow users to specify a custom path for email templates. Once specified and saved, emails will not use the default folder. Verify that the new path is correct, otherwise, no email will be sent due to no file being found. Why would you use a custom email template directory? As in most cases, the default template folder is overwritten during version upgrades, meaning changes will be reverted back to default. Users can avoid this issue by using a Custom Email templates folder since it will remain unchanged during the upgrade process. Note that some releases might introduce new logos or emails that will be missing from the custom folder. In this case, Sisense recommends either re-doing the folder content or copying over missing files. Below are additional resources from the Sisense Knowledge Base: Personalizing the Analytics User Experience with Sisense Themes (https://community.sisense.com/t5/sisense-community-blog/personalizing-the-analytics-user-experience-with-sisense-themes/ba-p/153) Replace the homepage with an embedded dashboard (https://community.sisense.com/t5/knowledge/replace-the-homepage-with-an-embedded-dashboard/ta-p/894) How to Disable Emails from Sisense (https://community.sisense.com/t5/knowledge/how-to-disable-emails-from-sisense/ta-p/181)Converting an Existing Sisense Widget to a Dynamic ComposeSDK Widget Component
Using either the widget Sisense API's, or the Sisense widget JS API object, it is possible to determine all components and parameters of a widget required to create an equivalent dynamic ComposeSDK widget component. This approach allows the extraction of all components and parameters of a widget, enabling the creation of an equivalent dynamic ComposeSDK widget component without directly referencing or relying on a specific widget or dashboard ID. The metadata of an existing widget contains all the information needed to create a dynamic version of an existing Sisense widget. It is also possible to use an existing widget ID and dashboard ID to render an existing widget in ComposeSDK, but this does not take full advantage of the capabilities of ComposeSDK to generate new widgets directly.
