Currently, a table must have static columns and rows defined before the widget will display data. It would be great to be able to dynamically build a table's rows based on * To expand on this, it would be great for the table to have the option to exclude instances with zero/no data from the list. For example, I would like a table that displays all MSMQ queue names and the number of messages in each queue - but not display anything if the current queue length = 0

@Ali Holmes Thank you! One more desirable thing would be the ability to reference properties (device and ILPs), not just datapoints. This would enable presentation of asset information, for example, assuming propertysources are producing results.

I agree with this 100%. Running in to this issue now. In my example, I would like a table showing a full list of VMware datastores and their used/free capacity. With how tables are set up now, I'd have to manually enter a row for each datastore, and manually update that as we add/remove/modify them.

I found this because I just tried for the first time to add a table and was floored that I must define every row by hand. In this case, I have to work around the lack of "bottom N" in graphs so I can watch for devices that have rebooted recently in one place. I want to put in this table all devices in a group, which seems like a no-brainer from a functionality standpoint. Having to manually define those and maintain forever is a non-starter. Can we please get the rows to be enterable as device groups and/or globs, as in other places? Thanks, Mark

This is something we're spec'ing out currently. It's likely we'll have to limit the dynamic table to a single datasource to ensure columns have the same number of instances, but it sounds like that will be sufficient for the examples provided?

Hi Ali -- thanks for responding! That sounds like it would make sense, but I can imagine some counterexamples. For example, datasources that are similar but not identical (different types of snmp_If* DSes spring to mind). I recommend allowing multiple DSes, but require the same datapoints. If the DP does not exist, then show a NaN. The next step would be to have a DP-mapping capability, but that seems overly complex. If we had it as described, I would definitely be happier than without it, of course! Thanks, Mark

Dynamic Tables (dashboard widget)

mnagel
Professor
7 years ago
@Ali Holmes Thank you!

One more desirable thing would be the ability to reference properties (device and ILPs), not just datapoints. This would enable presentation of asset information, for example, assuming propertysources are producing results.
Will_Simon
8 years ago
I agree with this 100%. Running in to this issue now.

In my example, I would like a table showing a full list of VMware datastores and their used/free capacity. With how tables are set up now, I'd have to manually enter a row for each datastore, and manually update that as we add/remove/modify them.
mnagel
Professor
8 years ago
I found this because I just tried for the first time to add a table and was floored that I must define every row by hand. In this case, I have to work around the lack of "bottom N" in graphs so I can watch for devices that have rebooted recently in one place. I want to put in this table all devices in a group, which seems like a no-brainer from a functionality standpoint. Having to manually define those and maintain forever is a non-starter. Can we please get the rows to be enterable as device groups and/or globs, as in other places?

Thanks,
Mark
Ali_Holmes
Former Employee
8 years ago
This is something we're spec'ing out currently. It's likely we'll have to limit the dynamic table to a single datasource to ensure columns have the same number of instances, but it sounds like that will be sufficient for the examples provided?
mnagel
Professor
8 years ago
Hi Ali -- thanks for responding! That sounds like it would make sense, but I can imagine some counterexamples. For example, datasources that are similar but not identical (different types of snmp_If* DSes spring to mind). I recommend allowing multiple DSes, but require the same datapoints. If the DP does not exist, then show a NaN. The next step would be to have a DP-mapping capability, but that seems overly complex.

If we had it as described, I would definitely be happier than without it, of course!

Thanks,
Mark
ErnieC
8 years ago
@Ali Holmes that is a good start, although I was told the same thing last November by my account manager. It's been almost a year and no progress has been made and this is still being spec'd out?

I also kinda agree with @mnagel - there shouldn't be a problem just NaN'ing the "bad" cell in the table. Doing one is a good start, but let's not be content with just that.

For what it's worth, you can kind of "ghetto" this up already with a line chart. The data and logic is already baked in, just displayed as a point on a graph over time, instead of the most recent datapoint.
Ali_Holmes
Former Employee
8 years ago
Hi @ErnieC, our Product team went through a reorg in May that resulted in a significant shift in priorities. I can assure you that this is in development and slated for v99 (phase 1) if all goes smoothly.
ErnieC
8 years ago
Fantastic, thank you for the update!
ErnieC
7 years ago
Glad to see this was released in v99. We will be playing with it over the next few weeks. Thanks!
mnagel
Professor
7 years ago
So close.... Why are we still pinned to 'TopN' for selectors? Can we please also have 'BottomN'? I know this can't be difficult from a programming perspective and it is really needed.

Thanks,
Mark