tag grid displays invalid values

[smithed]

I've dropped down a tag grid and configured it to show a variety of tags. For a moment after hitting refresh or loading the dashboard, it works (left half of image below). After about 2-3 seconds, it turns into the table shown to the right. The tag grid has default settings except I added a tag query value. The big built-in tag viewer table works fine.

The console log is below, although nothing seems to pop up in relation to hitting the refresh button:

jquery-1.11.1.min.js:3 The specified value "!" does not conform to the required format.  The format is "#rrggbb" where rr, gg, bb are two-digit hexadecimal numbers.
buildFragment @ jquery-1.11.1.min.js:3
m.parseHTML @ jquery-1.11.1.min.js:4
m.fn.init @ jquery-1.11.1.min.js:2
m @ jquery-1.11.1.min.js:2
$.fn.spectrum.processNativeColorInputs @ spectrum.js:991
(anonymous) @ spectrum.js:1884
j @ jquery-1.11.1.min.js:2
fireWith @ jquery-1.11.1.min.js:2
ready @ jquery-1.11.1.min.js:2
J @ jquery-1.11.1.min.js:2
VM907:1 GET https://n9244489/plugins/dashboardbuilder/heliumUI/node_modules/ni-webcharts/messages/Webcharts_en.properties 404 (Not Found)
(anonymous) @ VM907:1
send @ jquery-1.11.1.min.js:4
ajax @ jquery-1.11.1.min.js:4
loadAndParseFile @ webcharts.min.js:13741
r @ webcharts.min.js:13741
$.i18n.properties @ webcharts.min.js:13741
(anonymous) @ webcharts.min.js:13747
(anonymous) @ webcharts.min.js:13747
webcharts.min.js:13741 Failed to download or parse ./node_modules/ni-webcharts/messages/Webcharts_en.properties
VM907:1 GET https://n9244489/plugins/dashboardbuilder/heliumUI/node_modules/ni-webcharts/messages/Webcharts_en_US.properties 404 (Not Found)
(anonymous) @ VM907:1
send @ jquery-1.11.1.min.js:4
ajax @ jquery-1.11.1.min.js:4
loadAndParseFile @ webcharts.min.js:13741
r @ webcharts.min.js:13741
$.i18n.properties @ webcharts.min.js:13741
(anonymous) @ webcharts.min.js:13747
(anonymous) @ webcharts.min.js:13747
webcharts.min.js:13741 Failed to download or parse ./node_modules/ni-webcharts/messages/Webcharts_en_US.properties

On a related topic, my tag names are currently in the form of url paths eg "resource/type/field". It didn't seem to have a problem with me making those tag names -- would you expect anything weird to happen with dashboard builder as a result? I've noticed that autocomplete doesn't work correctly, but the normal graphs and numerics and strings all seem to work ok.

[GreyGrey · Accepted solution]

Tag names shouldn't have "/" in them. Since we're working with web services, putting a "/" in the name will mess with SystemLink's ability to get that tag's information. I wouldn't be surprised if this is causing the behavior that you are seeing. Can you try replacing the "/" with a "." instead?

We recommend using periods for organizing tags instead of forward slashes. However, we probably shouldn't let users set the name of a tag to something with a "/" in it.

The Dashboard Builder has a Namespace Depth field that can be used in combination with the Tag Query to look only for strings before the depth (number of periods) that you specify. Also, you'll notice that we use this organization scheme for the health monitoring tags for SystemLink Managed Systems.

[smithed]

Yep, that was it. Works just fine now (well I also updated to 18.1, but I'm going to assume it was the /)

The namespacing thing is working well now too -- we're doing the same thing, just a different delimiter.

Is there a list of restricted characters (or perhaps more accurately, characters that "might do bad things")? Since our stuff is all url-based we have an internal restriction against anything that should normally be escaped in a url -- should that pretty much cover everything in systemlink?

[GreyGrey · Accepted solution]

For now, I would avoid using any characters in tag names that are used by the Dashboard Editor for binding. Specifically, I would avoid the following characters:

• "?"
• "(" ")"
• "&"
• "/" "\"

We hope to in future versions of the Dashboard make it work for tags with those characters in them but for the time being, I would avoid using those in tag names.