ContributionsMost RecentNewest TopicsMost LikesSolutionsRe: Ability to increase the number of recently used Drill-in fields that display when right clicking Thanks for the response TriAnthony. Our data model has 82 tables and 1,134 fields. Each widget is specific to a particular fact table and it's related dimensions. Therefore, creating an overarching drill-in hierarchy is not feasible for us as it would insinuate that drill-in relationships are relevant to a particular widget, when in fact they would result in "N/A" data leading to customer confusion. If we were able to create and manage drill-in hierarchy templates that could be applied at the widget level for a specific set of fact/dimension tables that would absolutely be beneficial. Otherwise, simply allowing for more than 5 "recent" drill-ins would allow the dashboard builders to pre-select the relevant drill-ins for a given widget. For now, we are just going to pre-define the 5 we that we can, and add text box notes on further drilling based on relevant, related dimensions. Ability to increase the number of recently used Drill-in fields that display when right clicking The UI limits the number of recently used drill-in fields to 5. I've attempted to write custom JavaScript to add additional entries to widget.metadata.drillHistory, and verified they are added to the array successfully, however the UI will only show 5 drill-in values. This is important because our customers need to be able to "slice and dice" data visually and the best way to do that on a single chart is by using drill-ins. We do not want customers to have to "Choose another" because nearly all of these customers are viewers and do not have or need extensive knowledge of the data model. Having an option to increase this, either as a dashboard JavaScript override, or as a feature in the configuration of the product itself would be very beneficial. Ability to configure BaseTableMaxThreads at the Data Group level Add the ability to adjust the BaseTableMaxThreads at the Data Group level. This will allow for "right sizing" memory allocation that is consumed during the build process. For example, I have low priority elasticubes residing in the default data group. High priority elasticubes reside in a "High Priority" data group with custom settings for "Stop When Idle", RAM, etc. Currently, our environment is configured to load 3 base tables concurrently (BaseTableMaxThreads = 3). This setting impacts both high and low priority data groups. I want to be able to set my low priority data group to only load one table at a time (BaseTableMaxThreads = 1) to reduce memory consumption on the server during builds. I want my high priority data group to continue loading 3 tables at a time. The trade off is the default data group will load data slower but will consume less memory/CPU during builds, freeing up resources for the high priority data group. Re: Enhancing dependent filtering functionality to allow for a subset-filtering Agreed. Same issue here where we have a survey form as the parent filter and it's dependent date and question filters below it. Not having the ability to lockdown the parent filter (the survey name) allows end users to select a different form, which may break the custom dashboard tailored to a specific survey. Unable to Load Dashboard We recently made a significant change to the table and field names in our data model in an effort to better organize and structure the way the data is presented when listed in a drop down. We knew this change would break most of our dashboards and were prepared to simply go into the impacted widgets, edit and correct any errors. However, we have some dashboards that throw a 500 error and do not provide the interface to edit widgets. The response from the API call is: {"status":"error","message":"Cannot read properties of undefined (reading '0')" I am able to access the dash properties via the REST API, but this is not an acceptable method for fixing a broken dashboard. Has anyone else run into this problem? We're running Linux Version: L2023.7.0.231