How to rename a custom property value?

We have thousands of nodes and related NodeRole-based alerts, so recreating a value is not an option.
Is it possible to rename a value somehow?

UPD: Wow, Solarwinds has released improved Custom Property editor in 2020.2.6, let's check it out, very promising! (comment below)

Find more posts tagged with

custom_properties

Accepted answers

All comments

omavel

Any ideas?

aLTeReGo

The Custom Property Editor allows for bulk editing, so you don't need to change each node individually.

omavel

After bulk editing I still need to change NodeRole name in thousands of related NodeRole-based alerts, because Custom Property Editor creates new property value, instead of renaming old one.

daham_bm

As per my understanding, you cannot rename the values in custom property unless via the Database itself. Possibly you can remove the old value, Add the new value and then filter the NodeRole and it should show you the 'unknown' values for old property nodes. then you can bulk update the nodes custom property to the new value.

HerrDoktor

as long as one single node has this value set in it's custom Property you can not delete/alter/etc it.

My suggestion would be:

- create a new value in that list with the correct name.

- Open Manage nodes and order by your NodeRole CP,

- select only Nodes that have App Server as that CP

- Bulk Change the value for ALL machines

- delete the wrong value

omavel

lol. After deleting a node role, all related alert conditions are resetted and shows me node role with id=1

HerrDoktor

This is expected behavior when you have fixed/Pre-defined values for the CPs. When you get into the underlying Database structure you quickly realize why.

if you are interested we can take this offline, as it would be a longer discussion

omavel

No offence, but If we talk about app architecture, I know about two best practices:
1. To use unique ids for different entities (and they don't have to be 1..2..3 lmao - it's now clear why).
2. Not to change anything without users explicit consent/permission/notification/whatever.
Custom property edit procedure should be revised. Because in the current situation I have to check every alert to make sure everything is fine - and this is so much work.

Omg, it was just a simple wish to rename a custom value! But it is so complicated with prod-ready Solarwinds.

Sorry for my engrish

HerrDoktor

I am not the programmer or a SolarWinds employee, I just tell you "it is what it is". Don't shoot the messenger.

As you seem to be proficient in SQL Stuff. you can change values in the Database of course. However if you break something by doing this, this is on you.

... von mir aus auch auf Deutsch, da hab ich kein Problem damit

jmodjeski

I have had this exact problem. The first time I needed to do this, I created a New Custom Property, With the New Name I wanted to use, Then using the Custom Property Editor page, I copied from the old custom property to the new custom property, 100 at a time since that was the limitation, This was tedious. When I satisfied that everything was copied properly I deleted the old custom property, If I had to do it again, I would build a script to make these changes via the API.

omavel

Wow, Solarwinds has released improved Custom Property editor in 2020.2.6, let's check it out, very promising!

We have a value to be changed:

Oh wow, EDIT FORM! Seems like we can do it without any difficulties

Btw, we have a node:

Also we have a classic noderole-related alert:

Let's try to rename it?
Besides, what could go wrong?
This is a new, improved editor!
...

Save.

Let's check.

Hm what? Unknown?

What about alert?

Omg. Why.

1. New "improved" interface pretending to rename a value.
But as old one, it only deletes it. At the same time, the old interface doesn't trick you, because it had "remove" button. New one has edit field.
Very, very bad UX.

2. Dependencies like nodes, alerts, etc are not taken into account - this is very, very bad.

New interface turned out to be a big bunch of nothing. The same functionality with worse UI.

mesverrum

So on the back end there is no entity to track for a "rename" of a value. It is just a table of strings with no unique identifier or anything so when you rename it there is really no relationship to previous instances of that string. It would likely require a total rework of the way that custom property values are treated across the whole application to create a rename option that could go out and replace all the places where the value is currently used by creating some sort of GUID for each value and wherever you use them you would have to refer to the GUID instead of just string matching like we do today. Would certainly make life easier in some scenarios to have a find and replace but I'm just putting it out there that it's probably around priority #40,000 on the to do list.

As a work around in the mean time I think the best you could do is use a SQL report that would be a modified version of this one to hunt down all the places where custom properties are used with your specific value and be able to change them yourself.

thwack.solarwinds.com/.../2609

omavel

Wow, thank you

jblankjblank

First thank you @mesverrum and @HerrDoktor for sharing your insight. And Thank you @omavel for your feedback. I have asked the team to log a fix for the behavior described above, as well as a request for the ability to "find and replace" these values also as referenced above.

You mentioned however "the same functionality...and "improved editor" but a worse UI. So was this because it didn't allow you to workaround this particular issue, or were there other reasons you preferred the previous UI? We would love to get more detail around your thoughts here. The first step we had to ensure was taken was not to remove critical functionality that is so vital to many customers, and then add updates where possible to improve or enhance the current functionality. The effort started within EOC, which now has the ability to manage custom properties, copy custom properties, and consolidate custom properties across multiple Orion Instances. From there we hoped that some of the changes we made would also benefit our users that have a single instance. So additions such as the ability to have a filter panel beyond a single group by option, as well as pulling in the Account Limitation builder to the web instead of having to access the Win32 app on the server we felt would be well received. These are just a couple of examples. If you have additional thoughts on what is missing, please let us know. Thank you!

bobmarley

I may have a workaround for you that I have used in the past to populate custom properties values.

You could create and alert trigger such as if custom property equals "app server" and custom property equals "Ansible" then an alert action to populate a new custom property field "application server". You will end up with two custom property fields, the old one and the new one. Then after all is populated you could remove the "app server" one. There is one thing to know, at least in my environment, you will need to trigger the alert by toggling it off and back on a few times as each time you trigger it it will update a thousand nodes or so. I think the alert action eventually times out. If you do it a few times it will eventually populate all of them.