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.Update and add new Highcharts modules for use in Sisense plugins
Update and add new Highcharts modules for use in Sisense plugins The JavaScript library framework Highcharts is natively included in Sisense and is utilized in many native Sisense widgets as well as in numerous Sisense plugins. Although Sisense typically does not alter the Sisense Highcharts library version with every release, the versions of Highcharts included in Sisense may change when upgrading to a new major version release. Highcharts can load additional chart types and other types of functionality via JS module files that contain code-adding features such as additional chart types, which can be used within plugins along with additional code to create additional widget types. If a plugin utilizes a Highcharts module, you can source the module directly in the "plugin.json" file's source parameter, as shown in this example: "source": [ "HighchartModule.js", ], To determine the current Highcharts version being used in your Sisense version, you can use the "Highcharts" command in the web console while viewing any page on your Sisense server. After identifying the current Highcharts version, you can find the corresponding module hosted on the Highcharts code hosting website using the following URL format: https://code.highcharts.com/${Highcharts_Version}/modules/${module_name}.js For example: https://code.highcharts.com/6.0.4/modules/heatmap.js You can save this module and upload it to the plugin folder or replace the older module JS file simply by copying and pasting the code directly. Be sure to update the "plugin.json" file to point to the new module file if the file name has changed or if this is the first time the module is included. Simply sourcing the module file in the "plugin.json" file is sufficient to load the module into Highcharts; no further code is required to load the module.Configure the color of links in jump to dashboard (Linux)
Configure the color of links in jump to dashboard Introduction When using the Jump to Dashboard feature in a widget, you may want to customize the color of links or clickable elements that open the modal dashboard. This can be done with a few modifications to the JTD plugin. [ALT TEXT: A table displaying data on the number of unique brands for various age ranges over a series of years. The age ranges are categorized as 0-18, 19-24, and 25-34. Each row lists the specific year from 2009 to 2013 and the corresponding number of unique brands for each age group, with values increasing over the years.] Step-by-Step Guide The two files that can be modified for this functionality are : The color attribute in the styles.css stylesheet file, where the color attribute can be set for the color attribute for the selector: div.fake-link [ALT TEXT: A screenshot of a code editor displaying a section of CSS code. The code includes styles for mobile navigation elements, with properties such as width, display, text overflow, and color. Specific styles are highlighted for a mobile jump menu list and a fake link, showing values like width set to 360px and color set to red. The interface is dark-themed with highlighted syntax.] The parameter in the Javascript file ./js/services/displayAndGetDashboardsFunctions.js in the function modifyPivot2Cells in the variable jtdStyles the parameter changed being color [ALT TEXT: A screenshot of a code editor displaying JavaScript code. The code includes functions such as `this.checkIfJumpable` and `function modifyPivot2Cells`, with syntax highlighting for keywords and strings. The editor window shows file paths for JavaScript and CSS files at the top.] [ALT TEXT: A table displaying data on the number of unique brands by age range and year. The age ranges are 0-18, 19-24, and 25-34. The years listed are from 2009 to 2013, along with corresponding counts of unique brands for each range and year. The table shows increasing trends in the number of unique brands from 2009 to 2013 across all age ranges.] In most cases the same color code would be used for both. Any valid HTML color name or HTML color code can be used. Additionally, if you expect to change the color in the future, you can add an additional parameter to the appConfig variable in the config.js file, you can call this new parameter linkColor , and import it into the displayAndGetDashboardsFunctions.js file, using this parameter the color can be changed via the config file in the future. [ALT TEXT: Screenshot of a code editor displaying a JavaScript file named "config.js." The code includes various configuration settings related to dashboard navigation and display options, such as `globalIcon`, `dashboardId`, and `linkColor`. The editor indicates "No results" at the top right.] [ALT TEXT: Screenshot of a code editor displaying JavaScript and CSS files. In the visible code, there are functions and variable declarations related to managing dashboards and styling cells. Syntax highlighting shows different colors for keywords, strings, and comments.] [ALT TEXT: The image shows a table with three columns. The first column lists age ranges, including "0-18," "19-24," "25-34," and "35-44." The second column indicates the years in which data was collected, spanning from 2009 to 2013. The third column shows the number of unique brands for each age range by year. The values vary, with notable counts for the age group 25-34 in the years 2012 and 2013, showing 887 and 593 unique brands, respectively.] Attached is a zip file copy of JTD with those changes, this zip will not automatically update to match the latest version of JTD so this should be used as a template of this changes, and do not overwrite the existing version of the JTD plugin on your server. Conclusion By following these steps, you can successfully customize the link colors for the Jump to Dashboard feature. Whether you modify the styles.css file, update the JavaScript function, or introduce a configurable option in config.js, these changes provide greater flexibility in styling. For long-term maintainability, consider implementing the config.js approach, as it allows for easy updates without modifying the core plugin files. The attached JTD zip file serves as a template for these modifications but should not replace the existing JTD plugin on your server. Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this please let us know.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)Advanced Pivot Widget Scripting - Combining Custom JAQL and the Pivot 2.0 API
While the Pivot Table Widget Type is a highly customizable and flexible Sisense widget for representing data in tabular form, certain use cases may be best achieved through custom code and scripting. The Pivot 2.0 JavaScript API facilitates the modification of existing pivot table cells, including updating cell values and adding data to cells not present in the initial results.Demonstrating ComposeSDK Styling Of Sisense Dashboard Widgets
Demonstrating ComposeSDK Styling Of Existing Sisense Dashboard Widgets When developing ComposeSDK embedded applications, there are three principal techniques for embedding or converting an existing Sisense widget. Discussing each method, and some of the benefits associated with them: Direct Rendering existing Sisense Dashboard Widgets with the DashboardWidget Function: The expedited approach involves rendering an existing Sisense widget directly using the DashboardWidget function. While this method ensures swift integration, it does not allow all data options of the widget to be edited within ComposeSDK or defined as variables, one of the features of native ComposeSDK widgets. Nevertheless, customization of other parameters, including styling, remains feasible based on the props used. Mandatory parameters include the dashboard and widget ID, which allow the rendering of an existing Sisense widget. Widget Recreation using ComposeSDK to Create Native ComposeSDK widgets An alternative method, detailed in this article, entails recreating the widget as a native ComposeSDK widget by employing an existing Sisense widget as a template for a new not directly linked ComposeSDK widget. Though potentially more time-intensive, this approach yields a fully customizable native ComposeSDK widget. It stands independent of any specific widget or dashboard on the Sisense server, enabling complete independence to changes made to the original dashboard or widget, or complete deletion of the widget used as the model. Loading Widget Metadata with the useGetWidgetModel function Leveraging the useGetWidgetModel ComposeSDK function provides a middle option, detailed in this article. It allows automating the return of widget metadata from an existing Sisense widget, facilitating dynamic modifications within ComposeSDK. This method balances somewhat the autonomy of entirely recreating a widget as a native ComposeSDK widget and rendering a widget as a Dashboard Widget. In this article, we will demonstrate and discuss the DashboardWidget rendering feature, a powerful capability within ComposeSDK that allows the embedding and rendering of existing widgets. The focus will be on exploring the large number of styling options provided by this feature. Among the properties of a DashboardWidget component, the styleOptions parameter determines the styling. This parameter accepts a DashboardWidgetStyleOptions object, which includes a large number of parameters documented in detail below and in this documentation page. To demonstrate a practical implementation of using these styling options, the following code example showcases a Compose DashboardWidget utilizing all documented parameters within the DashboardWidgetStyleOptions object. import { DashboardWidget } from "@sisense/sdk-ui"; export function ComposeSDKChart(props) { let styleOptions = { "backgroundColor": "lightblue", "border": true, "borderColor": "green", "cornerRadius": "Large", "shadow": "Dark", "spaceAround": "Large", "header": { "hidden": false, "titleAlignment": "Center", "backgroundColor": "lightblue", "titleTextColor": "blue" }, "height": 200, "width": 200 }; return (<DashboardWidget widgetOid={'65ab8958857ff900335db870'} dashboardOid={'65ab8948857ff900335db86e'} styleOptions={styleOptions} title={"My Chart"} />) } The final result in this example is the widget below, showing the effect of this styling in this specific case: Discussing each style option individually, including the type of parameter accepted by each style setting. backgroundColor: Type: string - Specifically a string containing an HTML color Description: This option sets the background color of the widget. In the example, the background color is set to "lightblue," a preset standard HTML color code that is equal to #ADD8E6 as a hex color code. border: Type: boolean Description: This option determines whether the widget container has a border or not. In the example, the border is enabled with the value set to true, adding a defined boundary to the widget that can be styled. borderColor: Type: string - Specifically a string containing an HTML color, Description: Specifies the color of the widget container's border. cornerRadius: Type: "Large" | "Medium" | "Small" - Three specific options set as specific strings Description: Defines the corner radius of the widget container, similar to the CSS property of the same name, allowing for customization of the widget container's shape. header: Type: object- Contains various parameters that control the styling of the header and title. Description: A style object to customize the widget header. It includes options like background color, divider line toggle, divider line color, header visibility toggle, title alignment, and title text color. header.backgroundColor: Type: string - Specifically a string containing an HTML color Description: Sets the background color of the widget header. header.dividerLine: Type: boolean Description: Controls the visibility of the divider line between the widget header and the chart. header.dividerLineColor Type: string - Specifically a string containing an HTML color Description: Specifies the color of the divider line, if visible. header.hidden Type: boolean Description: Toggles the visibility of the header and title. header.titleAlignment Type: "Left" | "Center" - Two specific options set as specific strings Description: Alignment of the title within the header. The example centers the title using the value "Center. header.titleTextColor Type: string- Specifically a string containing an HTML color Description: Specifies the text color of the header title. height: Type: number - Number in pixels Description: Sets the total height of the widget in pixels. If not explicitly set will use the height of the container. width: Type: number - Number in pixels Description: Sets the total width of the widget in pixels. If not explicitly set will use the width of the container. shadow: Type: "Medium" | "Light" | "Dark" - Three specific options set as specific strings Description: Defines the shadow level of the widget container, similar to the CSS style of the same name. Effects styling only when spaceAround is defined. spaceAround: Type: "Large" | "Medium" | "Small" - Three specific options set as specific strings Description: Specifies the space between the widget container edge and the chart. With these styling options, one can modify the visual styling of a ComposeSDK DashboardWidget, enabling a large amount of style customization for an otherwise unchanged existing dashboard widget selected from an existing dashboard on the Sisense server. While ComposeSDK DashboardWidgets may not offer the extensive modification capabilities available to native ComposeSDK widgets, such as the ability to completely modify all of widget data options, they still provide a large degree of extensive visual customization through the use of styling options. Share your experience in the comments!
Replace the homepage with an embedded dashboard
Introduction: By using the re-branding API you can replace the default homepage with a specific dashboard. (For further explanation of the branding functionality please read this article.) Keep in mind you need to leave only what you change ("string" is just a place holder) Solution: In the Sisense Web Application, click ADMIN at the top right, and then REST API, followed by REST API Reference. Select REST API version 0.9, click /branding and then click the POST operation /branding. Use the POST call and add your server name and dashboard link (See below for example) [NOTE: add "/" character before the "#" character to allow the link to work in Firefox and Internet Explorer 11] { "homePage": "http://SisenseServerName:8081/app/main#/dashboards/57d1270774709bdc3f0000a7?embed=true&r=false" }Modifying Email Report URLs
Introduction When embedding Sisense in a parent application, there will be a need to route email reports to your parent application dashboard URL. For example, when a customer will load a dashboard in the embedded application, the dashboard URL might look something like this https://endcustomer.appowner.com/division/analytics?sisense_url=%2Fdashboards%2F{dashboard_oid} While the original Sisense dashboard URL might looks something like this: http://endcustomer-bi.appowner.com/app/main%23/dashboards/{dashboard_oid} In this case, when a customer receives an email report from the application, for instance to view a dashboard that was shared with them, they will be routed to the original Sisense dashboard URL and not the parent application URL. Solutions This article proposes two solutions to this: 1) Change the Alias field in the Admin/Settings of Sisense to the parent application URL. If the parent application dashboard URLs match this pattern: http://subdomain.domain.com/app/main%23/dashboards/{dashboard_oid} Then this solution will work. But, in case the parent application dashboard URL must be manipulated, you will need to apply the second solution. 2) Manipulate the embedded url token in Sisense templates. Let's use the dashboard share report as an example. If we open: path/to/email/templates/dashboard_report/html.ejs We will the see following: ... <td align="left" bgcolor="#ffffff"> <a name='dashboard' href='<%= url %>' target='_blank'> <img src='cid:<%= images[i] %>' id="<%= images[i] %>" name="<%= images[i] %>" /> </a> </td> We notice that the anchor tag has an EJS expression as the reference for the hyperlink: href='<%= url %>' The url token in this case evaluates to the original Sisense dashboard URL: url = http://endcustomer-bi.appowner.com/app/main%23/dashboards/{dashboard_oid} We can use JavaScript replace method to manipulate this token to match the parent application dashboard URL as so: <a name='dashboard' href='<%= url.replace('http://endcustomer-bi.appowner.com/app/main%23/dashboards/', 'https://endcustomer.appowner.com/division/analytics?sisense_url=%2Fdashboards%2F') %>' ... </a> When the email will be generated, the URL will resolve to the expected endpoint: https://endcustomer.appowner.com/division/analytics?sisense_url=%2Fdashboards%2F{dashboard_oid} and direct the customer to the dashboard in the parent application. * This solution was tested on Linux LA version 7.4.1.571 and Windows version 7.4.Email Troubleshooting - Sisense 7.2+
This guide will demonstrate a few official first steps for troubleshooting many of the common issues that we see with the emails portion of the Sisense Application. This guide exclusively focuses on Sisense Version 7.2+. Please follow all of the relevant steps in this article to troubleshoot the issue initially, and, if after performing these steps you still experience an issue, our support team will be more than happy to assist you. Basic Troubleshooting Step 1 - Check Configuration: In Sisense Version 7.2, the framework of the web application moved from an IIS hosted platform to a NodeJS application infrastructure. In doing this, all elements of the application are now hosted in "microservices", which are processes that run as tasks on the server and control particular application components. The creation, sending, and logging of emails is performed by the galaxy service (Sisense.Galaxy in the task manager), while the scheduling of the email exports is managed by the Jobs service (Sisense.Jobs in the task manager). As such, the first step to troubleshooting any email issue should be to ensure that the "send emails" setting of the application is on: Note: If you are not seeing the email option in your sharing dashboards module, it is likely that this setting is turned off. Step 2 - Check Plugins and Customization: Once we have confirmed that the emails are turned on, and we expect to see emails, the next step is to disable all of the plugins on the server for another round of testing. Common reasons for email failures: Unsupported, community plugins Out of date officially supported plugins Custom scripts Once all of the plugins are turned off, restart the following services, then send a test email: Sisense.Plugins Sisense.Galaxy Sisense.Gateway If the email comes through successfully, then walk through the plugins testing all possible plugin combinations until you are able to determine exactly which plugin is the culprit of the issue. If the plugin is an officially supported plugin, check to see if there is a newer version to install, and if there isn't a newer version, please open a support ticket documenting the exact replication steps and plugin name for our product team to update. If the plugin is an unsupported community plugin, look through the comments on the page to see if the author has updated the plugin recently or provided new code, and if not, feel free to comment on the page and see if the author is able to update the plugin or not. Repeat this same process for any custom dashboard or widget scripts as well. Step 3 - Check Reporting Engine (Only Relevant for Dashboard Reports) Many users schedule emails to provide them with updated dashboard reports at certain regular intervals (or in an ad hoc manner). To create these emails our application relies on its internal reporting engine to export a PDF version of the dashboard itself. If this component is failing on its own, then it will also affect the emails being sent out, as they will not be able to generate the content of the email. To test this, open the dashboard that you are trying to email a report of, and attempt to download a PDF version of the dashboard locally, using the PDF button in the top right of your dashboard. If you are able to export the PDF successfully, then the issue is likely not caused by the export engine. If the user receives an error, or the PDF does not download correctly, then this could likely be the root cause for the email issue as well. If this is the case, please refer to this document for further troubleshooting techniques specific to export to PDF: Error Exporting To PDF Step 4 - Check Pulse (Only Relevant for Pulse Emails) Many users also rely on Sisense's email service for pulse notifications. Similar to the Reporting Engine section, if there is an error with the pulse mechanism, then it will likely affect those notifications as well. You can test this in a very similar manner as the PDF exports, by forcing your data to meet one of the criteria for a pulse alert, and then checking to make sure that the condition is seen in your Pulse tab of your application, and to check whether or not you received a notification through any other delivery method (mobile, on site popup, etc.). If you see that the Pulse system seems to be failing as a whole, please refer to this documentation for troubleshooting Pulse: Pulse Troubleshooting Step 5 - Restart Services Sometimes, for a variety of reasons, a service reset may be required by the system. In such a case, try restarting the Sisense.Jobs, Sisense.Gateway, and Sisense.Galaxy services. If after doing such, the test emails are still failing to be sent out, zip up your Sisense Galaxy and Sisense Jobs Application Logs, and open a ticket with our support team. The logs can be found at the following paths: C:\ProgramData\Sisense\application-logs\galaxy C:\ProgramData\Sisense\application-logs\jobs-service If a restart of the services does fix the issue, you can still send the Galaxy and Jobs logs to our Sisense support team for further root cause analysis to determine what was the source of the issue. Step 6 - Open a Support Ticket If after performing all five of the steps above, and your issue is not addressed anywhere else in this document, please take a zip file of the following two log paths, and open a ticket with our support team. C:\ProgramData\Sisense\application-logs\galaxy C:\ProgramData\Sisense\application-logs\jobs-service In the ticket, please provide them with the exact issue that you are experiencing (with screenshots if possible), a rough time stamp of the last time a user tried to send an email (this makes sifting through the logs much easier), and any other details or history, particularly about any changes made at a software or hardware level that may be relevant from the time when emails were last working to the time at which they stopped. Custom Email Server Troubleshooting By default, Sisense emails are sent from a sisense-admin@sisense.com email address. This settings, however, can be modified to be sent from an email of the user's choosing using two different methods. The first is by contacting Sisense to use our custom MailChimp email server. To use a personal email, but through Sisense's email server, you will need to follow the instructions at the following documentation: Changing The Sisense Email Sender Otherwise, users can opt to host their own email server, and simply connect it to the Sisense application through Sisense's REST API. The documentation for that setup can be found here: Setting Up a Custom Email Server Troubleshooting User's Custom Email Server While the set up and maintenance of a user's own custom email server is considered out of the realm of typical Sisense support, the most frequently reported issue from using a custom email server is network connectivity from the server running Sisense to the custom email server itself. To troubleshoot this issue, we recommend trying to run an email through the server without it interacting with Sisense. To do this, a user can use the send mail message command in Microsoft's PowerShell from the Sisense server. Documentation for that particular command can be found here: Powershell: Send-MailMessage The commands to test should look something like the following: $cred =new-object Management.Automation.PSCredential <"EMAILTOBEUSED@DOMAIN.COM">, (<"EMAILPASSWORD"> | ConvertTo-SecureString -AsPlainText -Force) Send-MailMessage -From <EMAILTOBEUSED@DOMAIN.COM> -To <EMAILTORECEIVETEST@DOMAIN.COM> -Subject "Test Email -Body "Test E-mail (body)" -SmtpServer <SMTP.SERVERNAME> -Port <NUMBEROFPORT> -Credential $cred If you are able to send out the email using that command, then there is likely some configuration or problem within your Sisense email configuration. If you are not able to send out an email using that command, then there is likely an issue with the configuration of the custom SMTP email server, and not necessarily within the Sisense program. Common Issues Dashboard Reporting Issues This issue is frequently caused by some sort of plugin interfering with the email export (especially after a recent upgrade), or by the reporting engine failing (see above). Dashboard Reporting Issues with Blank Email This issue typically occurs when the template for a particular email that was trying to be sent out is missing. Please ensure that the server has all of the following templates in the following file path: C:\Program Files\Sisense\app\galaxy-service\src\features\emails\templates No Emails are sent, Galaxy log shows {"reject_reason":"unsigned"} This error message indicates that "senderEmail" is changed, but domain is not verified in Sisense’s Mandrill email service. Please add DNS and DKIM records and contact support in order to verify the domain. Email Rebranding is not Showing Please first make sure that you followed the following instructions: https://docs.sisense.com/main/SisenseLinux/white-labeling-sisense-in-linux.htm Also make sure that you're changing the files located below: 7.4+ - C:\Program Files\Sisense\app\translations\en-US\email-templates.js 7.2-7.4 - C:\Program Files\Sisense\app\translations\en-US\languages.js Then restart the Sisense.Galaxy service
