nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Asset Management: Use Case of Inheriting Attributes?

Sandro Leone - EPS

Hi community,

can anybody enlighten me on practical use cases for the feature to inherit attributes in Asset Management?

I've now set up a structure for a client in the following way:

- Hardware

-- Desktops

-- Laptops

-- Smartphones

The 1st level, Hardware, contains all attributes that are shared between all of the 2nd level object types. It is also an abstract object type. So far this has been very practical for not having to always enter the same attributes when creating a new object-type. I guess this would be the most practical use case imo?

Because I have now encountered a problem which forces me to import all the objects anew. I wanted to set a different attribute as label, but just for the "Smartphones" object-type. But this is not possible, as the label in this case has to be the same attribute across ALL object-types underneath "Hardware".

As I think this is working as intended, but is forcing me to redo everything, I'm wondering if it's even worth it to use inheriting attributes if you are not 100% sure nothing is going to change? Is anyone able to share some good use cases of utilizing "inheriting attributes"?

Accepted answers

Jeroen Poismans

Hi and welcome to the community!

Let's start with a quote: "If you fail to prepare, you prepare to fail" :-)

Just kidding of course but you should think and prepare your "data model" before you start implementing in Assets. Because indeed and as you experienced, it's a pain to change afterwards.

There are some advantages in inheritance between objecttypes. For example we will stick to your object types and have a shared SerialNo. Here are some that I think are important.

SerialNo will have the same atttributeID across the different ObjectTypes. So if you want to address it in a script or any other way using D, it will be the same. Also when consuming your asset data in other tools, BI ... etc, this advantage will be clear.
If SerialNo is not inherited, try making a list view from the parent (Hardware) displaying the children with SerialNo attribute. In this case it is a different attribute and your list view will then have a SerialNo column ... for each different ObjectType.
Overall consistency in your CMDB where assets that share the same traits have the same data.

The first one obviously is the most important and my developer heart bleeds if you don't use inheritance in this case (compare it to Object Oriented Programming and inheritance there). That being said ... it is a personal choice :-).

Hope this helps!

All comments

Jeroen Poismans

Hi and welcome to the community!

Let's start with a quote: "If you fail to prepare, you prepare to fail" :-)

Just kidding of course but you should think and prepare your "data model" before you start implementing in Assets. Because indeed and as you experienced, it's a pain to change afterwards.

There are some advantages in inheritance between objecttypes. For example we will stick to your object types and have a shared SerialNo. Here are some that I think are important.

SerialNo will have the same atttributeID across the different ObjectTypes. So if you want to address it in a script or any other way using D, it will be the same. Also when consuming your asset data in other tools, BI ... etc, this advantage will be clear.
If SerialNo is not inherited, try making a list view from the parent (Hardware) displaying the children with SerialNo attribute. In this case it is a different attribute and your list view will then have a SerialNo column ... for each different ObjectType.
Overall consistency in your CMDB where assets that share the same traits have the same data.

Hope this helps!

Sandro Leone - EPS

Hi Jeroen,

thank you very much!

I've noticed this as well yesterday when trying to create reports and dashboards.

So, am I assuming this right that if I want to keep for example both object types "Desktops" and "Smartphones" under "Hardware", I essentially have to decide what's more important to me - having different labels or being able to pull data from a shared attribute id?

We have talked about a data model in advance, but I did not know that inheritance also means setting one attribute (which has to be from the top level object type!) as the label for the whole "group".

My heart bleeds as well - but since the customer wants to display the name for Desktops and the s/n for smartphones... This seems like the only way (apart from creating the Smartphones object type outside of the Hardware group, which does not make sense either).

Jeroen Poismans

For me it makes sense that OT's of te same type share a label field. You could however (with automation or configured in your imports) let the label field be populated with whatever data you want.

Smartphones could get the label field populated from s/n, as the desktops could get the asset tag or devicename from you import.

Alternatively, you could argue another setup where you put all mobile devices under another parent ObjectType, only for mobiles (smartphone, tablet, eReader ...)

Sandro Leone - EPS

Actually, this is a good idea. I'll have to discuss this. But I like the approach!

Thank you very much jeroen!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

asset-management

jira-service-management-cloud