Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Daniel_Fischler
Contributor
Contributor

Object Color and Gateway Color

We recently upgraded te management from R77.30 to R80.10.

Before we hat selected the visible colors and named them using the color editor.

In R80.10 this behaviour is a little bit different and confusing:

  • You can still manage the colors (and name them) if you open the color manager on a checkpoint object
  • You can manage the colors (but NOT name it) if you open the color manager on a ordinary host.

I looked into the database using GUIDBedit and was suprised, that every color is existing twice. Once for the checkpoint object (with the configured name of the color in a field) and once as a default color for the ordinary hosts.

For me this looks like a bug or a not finished solution. Why should I use a different color palete for these different objects. And why am I not able to name the ones for the hosts?

does anone have a solution for this? Is this an issue caused by the upgrade? Any ideas how to harmonise the colors?

CCSM-E | CCVS
0 Kudos
9 Replies
Tomer_Sole
Mentor
Mentor

Hi, generally we recommend our users to use the new Tags to give meanings to objects. This way, you can search for all objects associated with one or more tags.

If you still want to paint an object with a color based on its tag association, you could make an API script for that. 

What do you think of this approach?

0 Kudos
Vladimir
Champion
Champion

Would be nice to have tag-to-color association selectable as option (i.e. checkbox). This way you do not have to remember running the API call every time new object is created.

BTW, I am not sure if it is an option, but can you make tagging mandatory (preferably for either select tags or object types)?

Also, is it possible for group members to inherit the color and/or tags if this is the only group they belong to?

0 Kudos
Tomer_Sole
Mentor
Mentor

Hi, these are good suggestions. 

Would be nice to have tag-to-color association selectable as option (i.e. checkbox). This way you do not have to remember running the API call every time new object is created.

You could make this a Cron job and have it paint the newly edited  objects based on their tags every hour or so.

BTW, I am not sure if it is an option, but can you make tagging mandatory (preferably for either select tags or object types)?

Custom conventions is in our plans for the next releases. At the moment though this isn't possible. 

Also, is it possible for group members to inherit the color and/or tags if this is the only group they belong to?

This could be a part of the tag-to-color logics that each customer can define based on his needs. Let me know if you have technical questions about the Management API.

0 Kudos
Daniel_Fischler
Contributor
Contributor

I think you missed the point. Why are there two different color list for gateways and for the rest. And why can I name the ones and not the others. 

Using tags is nice but is another story. Colors are there but are not as usable as before. With the setup with two different color schemes it is close to unusable. 

CCSM-E | CCVS
0 Kudos
Tomer_Sole
Mentor
Mentor

Going forward, both will have the same color scheme, and the same behavior. This is why I wanted to focus on the new recommendations. 

We are aware of the limitation of unsyn'd lists and will fix it in our next releases.

0 Kudos
mbaeck
Explorer

Hi,

I just migrated to R80.30 very lately and noticed this issue is still persistent as described in the opener's post.

We (several admins on same FW) used to have color conventions applied to 3000+ objects. It's impossible to maintain now. Is this bug still on your list?

0 Kudos
pnorman821
Participant

Hi,

We are are running a mixture of 80.20 and 80.30. Keeping control of object colours and implicitly the objects purpose was straightforward in R77.30. Now in R80.20/R80.30 you have something called the object editor (for new host objects etc) and when looking at the colours on a gateway object you have the color manager. All of our colour definitions (different network zones) are present in the color manager but not present in the color editor when we are trying to paint a new object for example..

This means that the colours used within the object database vary greatly and has gradually degraded.. 

Has this been fixed in R80.40 or has it still not yet been fixed? Anyone else have any other tips on how to best manage this?

Thanks - Paul N

0 Kudos
pnorman821
Participant

Hi - Does anyone have any further comments on my last post?

0 Kudos
Colin_Campbell1
Contributor

HI,

 

I have recently jumped from R77.30 to R80.40 and find the inability to change colour (proper spelling 🙂 names frustrating. While tags might be the "way of the future" colours provide a visual cue. I can look at a rule and tell a myriad of things just from the object colours. So being able to name the colours makes it easier to maintain the correct colouring of objects and keep those visual cues accurate.

 

Colin

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events