I’m trying to improve the legibility of our statuses in Shotgun. What I would love to do is to use text rather than icons. I noticed that the builtin icons “Active” and “Disabled” have their display_type field set to “html” and they use the html field to include the text as a label. This would work great for me!
However, it seems that there is no way through the web UI to create these html type icons. I tried through the API (also where I investigated the Icon fields), but the default API Admin group does not have permissions to create Icon entities.
I was wondering if I’m missing something here, or if I should request a change to my sites permissions?
Good sleuthing , I’m glad you found a solution for your needs. I think the allowed custom html miiiiiiiiiight be an oversight, so while it works now, I would just caution you that this probably isn’t an intended design feature and you might not want to rely on it 100%. If it were intended, we’d definitely have a better way of rendering the status icon in the custom icon selection window (as you noticed, it’s not pretty).
That said, you’re probably okay for the interim. Enjoy!
Thanks for the heads up. It did seem weird the way the Active and Disabled status icons are setup using the html field. I’m going to continue using these for the time being, I wrote some scripts to manage the html icons I’m creating so it’s easy enough to delete them all if need be.
Let me tell ya, it does wonders for legibility!
I would love to see some display settings for status fields.
Hi Dan,
I have come across this issue so many times with various clients. “What do the icons mean!?” Your solution is interesting!
Recently I have just been creating a whole new list based field and entering what statuses I want to use here and replacing the icon field entirely.
Hey folks! @jlp.vfx’s idea is not a bad idea, and definitely isn’t one to discount out of hand, but something I want to advise about is this: it’s possible that you’ll lose some performance if that’s a solution you decide to implement on a large scale. Our native status fields are well-indexed against common use cases, so if you decide to use your own status lists (or list fields) entirely, please be aware that for larger data sets, you might see slower responses for complex queries that leverage the non-native fields, because they won’t be able to take advantage of the same indices.