Colors Pattern Customization

[CME64]

New Features:

• new control called "ColorsLine" to select multiple colors for better adjacent visibility and easy control
• dashboard panels' series default colors can be customized per panel or dashboard with respect to old features like aliasColors and the default color pallette (backward compatible)

Expectations:

1. you will find a new setting in the dashboard settings page with a switch button and a ColorsLine control
2. you will find a new setting in the graph panel (only this panel so far because it's the only one using coloring for series in the package) settings page with a switch button and a ColorsLine control
3. when you apply a custom colors pattern into the dashboard settings it will apply to all panels that implement that feature within the same dashboard (inherit the colors)
4. when you apply a custom colors pattern into the panel (graph so far) it will apply only to that panel overriding the inherited colors
5. if you don't apply any customizations the default colors pattern will be used
6. series will cycle colors among the pattern defined in respective order
7. alias colors will override all colors settings for the specified series

how to use the control:

1. if the switch is turned off (custom colors) the colors cannot be modified (view only mode), turn it on to start the customization
2. click the plus (+) button in order to add more colors (there are (+) buttons between each couple of colors too to insert in the middle and they appear on hovering the area)
3. new colors will be added randomly everytime you add one (using the original colors pattern as the source)
4. click on the color to display the color picker and change it to your liking
5. use CTRL+Click on the color to remove it

notes:

1. changing colors will only affect the rendering an it will not request the query everytime.
2. series will use the colors from the color pattern in respective order and cycle back if the colors are less than the series
3. even if you define custom colors, alias colors will still apply and cannot be affected until unconfigured
4. you can set the colors from the json of the panel or the dashboard by adding string hex colors array in the property "colors" (to keep things clean in the UI you should set customPalette to true when filling the colors)

[CLAassistant]

All committers have signed the CLA.

[CME64]

@torkelo Please review the code, I tested it and it was working bug free.

I will make an MD file later as a developers' guide on how to use the new control and integrate the new feature of coloring into their panels but that's not mandatory right now.

the auto checker seems to have failed due to the comparison it's making to a snapshot which will never match the new model because it's changed. also the lint check failed because of access permission denied, sounds like a strange thing with the shell file.

BTW I had to take the liberty to change the lint check on staged changes a little because the pattern defined for the go files was failing (not correct syntax) so I changed it to pkg/. and it formatted all go files.

[ryantxu]

@CME64 -- you may want to look at the PR and make sure it is only including things you really intent to change... it looks like it has changed 1800 files!

[torkelo]

Please open a feature request describing your use case / scenario (problem) and how this solves that use case / problem.

We will then have to wait some time to gauge the interest in that feature request. The demand for a completely custom series color palette has not been high (no feature request opened in 5 years for this). So it's not likely this will be merged. One way I see this could be done would be for custom palettes & named palettes that could be defined in a config file in the backend, and set as default on the server, org & dashboard level.

[CME64]

@ryantxu that's due to the project being a TS & TSX, all those files are generated/compiled files. I have only added one file and modified like 5 or 6 others. this could be due to the changes to the model of the dashboard which is a main component of the system propagating throughout the files.

@torkelo I will submit a use case for this feature, I have only developed it when it was requested many times by my company's clients at work and thought I should share it into this great project the proper way with UI controls and ease of use instead of just modifying the json.

do I need to reference this PR in the request in a specific format? and what's the procedure you're following to gauge the interest of a feature?

[torkelo]

and what's the procedure you're following to gauge the interest of a feature?

thumbs up votes on the feature request issue.

@ryantxu that's due to the project being a TS & TSX, all those files are generated/compiled files. I have only added one file and modified like 5 or 6 others

Follow the building from source docs, the webpack commands (yarn start) does not generate any js files in the source directories, only generates output in the public/build directory which is git ignored

[CME64]

@torkelo yes most of the files included are from public/dist and I'm pretty sure it's not ignored
can this PR be reopened after the feature request approval or will I have to redo the conflicts resolution later?

[torkelo]

yes, if you can fix a PR that only includes your actual changes that would help.

[CME64]

@torkelo Seems difficult to do after the push. What if I push a change to the ignore file and you try to merge again, it may show less file changes while ignoring the public/dist directory. What do you think?