Having a text description of dimensions / indicators
I would like to have the possibility for a cube designer to provide a description per dimension. The dashboard designer would be given an help on the meaning of the data he is bringing in his report. The help text would show up on mouse over (tool tips)
Elasticube Build Behaviour - Upsert
Currently, the "Upsert" build behavior is only available for Build to destination. It would be great if we were able to utilize this feature in our Elasticube model where we are not building to destination. We have numerous tables containing created date as well as updated date that are attached to an id field but are unable to use the updated date field since this will bring in duplicate (or more) rows per id which we can not have. Ranking duplicates and filtering out is not a sustainable with the size of our datasets. The ability to look at the id and updated field would solve this issue without the need for a complex workaround in our data source (Big Query). Thank you!
Usage Analytics- Track Field Usage Across Dashboards
Idea: usage analytics reports can tell what reports use a certain field? Filter by a certain field in the usage analytics report and you will see all dashboards using that field. It would also be beneficial to track table usage in dashboards too. Use Case: region will be renamed to region_usa in our sql query and this could potentially break dashboards. to be proactive, i would like to know what dashboards are currently using the field 'region' so that I can redirect them to the correct field, 'region_usa' once the sisense schema & sql has been updated.Tool to find common data model problems
People sometimes build bad data models. Rather than them doing more training (or asking me to help), you could build a tool that points out common problems. The user would click a button, wait a minute or so, and then get a list of potential problems and suggested changes. The tool would describe an example using their data that they can use to prove the problem (e.g. "filter a widget by Location and Date and then you see it's double counting the Dollars field"); that would be more motivating than an abstract argument. Not only can they debug themselves, doing so will be better than training for teaching them to design better data models. Here are my ideas for issues to look for. They might not always indicate a problem, but you can point them out for the user to decide. Do they use a convention for distinguishing Fact and Dim tables? Typically "fact" and "dim" prefixes for table names. Does any widget use a dim-table field in an aggregation in a Values pane formulas? Does any widget use a fact-table field in a non-values pane, or as a members filter in a formula? Do any dim-tables join to a fact-table via another fact-table? Does any pair of tables have multiple relationship paths of the shortest length? (Should be only one short path and it shouldn't include a fact table, but there might be several longer ones via other fact tables.) Any many-to-many relationships? Sometimes this is intentional and the user is meant to select a single item from a dim-table, so maybe ignore it if all uses in widgets filter one side of the relationship.
Here are some improvements looking for better usability
1. View all history of builds and its corresponding logs from the cubes. Because, I could not see the last build failure reason, if another build got started. I need to wait for another build to complete or fail. 2. View all history of changes and provide a way to revert as in Google docs for both the cubes and dashboards. Some times, if something went wrong, we should just be able to revert to the previous version and continue from there. 3. Provide a way to view the list of cubes in the queue waiting for the build. Also, allow remove or disable them for a period or rearrange the queue to build. This will help in prioritizing something manual on demand. 4. If a cube build fails due to the memory or other configurations issue, provide suggestions like what has to be changed and based on what before triggering another build. 5. Provide a page to derive the suggested the configurations like memory, cpu, timeouts etc by collecting details like 1. Number of cubes, 2. average cube size, max cube size, min cube size, or number of cubes by size range say <5g, <10G, <20G, <40G etc.., 3. Frequency of the build per cube etc.. 6. Provide a page to view all the slow running dashboards, slow running queries and some suggestions to improve it. 7. Some times, if a dashboard got changed and republished, it is not getting applied to all the users. Provide a way to view the version of the dashboard the user may view. 8. Between builds, if there is not much change in the data, Sisense build should go faster. Provide a way like one common place to build each table from other sources individually and keep it ready. From there, if we build say functional cubes, it should build in flashing fast using the locally stored data. I see the cubes are pulling the data faster from relational db but very slow from mongodb. Now, if we are pulling data from another sisense cube or from the source no big performance difference. 9. Also, I am not sure, if we are restarting the nodes, should we necessarily mark the cubes in queue as failed, instead adding back to the queue as it was before the restart and just marking the actual cube got failed should be good enough. More later .. Thanks, Muthusamy JEasier way to view build history of a Cube
While editing/viewing a cube data source, you can view the logs of the last build, but can't easily see the overall history of builds for that one cube. It would be nice if you could click on the "..." menu and choose View Build History. A dialog box would pop up showing the most recent 10 builds (or whatever), sorted by date, with start/end datetime, duration, success/failure, etc.Reusable/shared connection information for data models
It seems strange to me that each time I need to add another table to my model, I have to re-enter all the connection (or pick a recent connection). If i have 10 tables in my model, they all have their own individual connection information. If a server name ever gets renamed, it'll be a crazy headache for us. There should be a place where you define the distinct list of actual database connections (one per server or database), give it a name, apply security, etc. And then when you go to add a table to a data model, at that point you pick from the previously defined available list of connections.Make user parameters more dynamic
**Please note this idea was migrated to the Product Feedback Forum from older submission areas** User parameters must be set and cannot be used for dynamic customizations. When setting up data models, these parameters cannot be included as part of a filter in the underlying query. We would like a way to reference a global or system variable that includes the username of the currently logged in user.