It also happened to me recently for a custom Pod (using external SQL Server and PostgreSQL datasources), colors would not change.
I'll also ping Engineering.
Not on my side, I was busy with other projects, not involving Dashboards for BSM.
Has anybody worked with BMC Support on this ?
Please share tips.
The only known issue with customizing colorConfiguration.properties is if the entry contains a space. For example:
// Does not work
Not Assigned = CCCCCC
// Does work
NotAssigned = CCCCCC
Other than that:
- check the location of the colorConfiguration.properties file
- check the name is correct, including case
- check there are no other files with very similar names that the product may be picking up by mistake:
- Restart BSM Dashboards Tomcat after making changes
I have never had any problem making this work, but I did work with one other customer who did. They resorted to removing and then reinstalling Dashboards and after this custom colours worked. No idea why it didn't work in the first place.
Thank you Jim for your answer.
The problem is still existing and is so frustating.
It seems that Dashboards uses a cache to show the colors; any editing to the colorConfiguration.properties does not apply to the application.
Please share your suggestions; but I think that reinstall the application is the only way.
I've opened a support case with BMC on this and they've opened a defect (SW0398453) It seems that there are times when the Dashboards application will assign a random color to a new data element and will then mark the color as "reserved" and nothing you can do to colorConfiguration.properties will change it.
There is a workaround, until BMC fixes this bug in a future release, but it involves using a Derby database tool and deleting rows from a table to "unreserve" them. This may or may not be supported by BMC but it works. I've used it and one of my teammates has as well with great success.
Let me know if you'd like further details and I can post them on here.
Finally we get to the bottom of this one - I could never reproduce it !!
When a chart is created, Dashboards will look for the value/color combination in the Derby database (Dashboards persistent data store).
If not found there, it will look in colorConfiguration.properties.
If still not found, a random color will be assigned.
This value/color combination is stored in Derby.
If a random color was assigned and you subsequently put the same value/color combination in colorConfiguration.properties file and then create a new chart, Dashboards will look in Derby first (as above) and since the value/color was stored when creating the previous chart, it will use that color.
If impacted, the workaround is to manually remove the entry from the Derby database.
To prevent the problem, ensure that the colorConfiguration.properties file is updated before creating the first chart that will use the custom value/color.
Yes, that is exactly what we've found and exactly what we put in the ticket when we opened it.
The problem actually comes from creating new datasets. The colors are picked when the dataset is created, not when it is used. Interestingly, exporting and then importing the datasets to another Dashboards server does not have this affect.
Note that colorConfiguration.properties seems to be case-sensitive in terms of value names, too.
Still waiting on a response to the RFE...