#2022 Attribute definition - share among classes

[Jeffrey Bostoen]

Just a very vague idea, but I've defining the same field on multiple subclasses for now. Yes, one could argue I could add it on the main class; but let's say it's not reallly enough subclasses to do that for now.

Imagine starting the other way around: attribute field definitions. Either you could have something very generic like you have now, and then in a class definition simply use something like:

<predefinedfields>
<field id="generic_field" xsi:type="AttributeString">
<sql>generic_field</sql>
<default_value/>
<is_null_allowed>true</is_null_allowed>
</field>
</predefinedfields>


<classes>
<class id="Example">
<fields>
<field id="predefined_field" xsi:type="Predefined" from="generic_field"/>
</fields>
</class>
</classes>

This could for instance allow the re-use of a "status" field, where typically now an AttributeEnum field is used (or an AttributeExternalKey). The datamodel XML would be much more compact. Changes would be applied for all classes at once.

[Pierre Goiffon]

Hello Jeffrey, to my knowledge we never has this need for now.
Can you describe some precise use cases ?

[Jeffrey Bostoen]

It's more to avoid lots of manual work in the XML files. I just did a project where I copy-pasted the same things ten times

Of course, if you use the ITSM Designer, then this is a non issue ;)

Not sure if it could have performance benefits.

[Guillaume Lajarige]

In the meantime you could use a Typology and pre-load values with the structural data?

[Hipska]

The same field on multiple classes that have the same parent looks more to a not ideal datamodel to me.

It would only add a little bit if the different classes don't have a common parent, but even then this templating mechanismn would make things far to complex, with no actual gain during regular usage of iTop.

[Jeffrey Bostoen]

This is why I launched it as an idea, I also don't think it will ever be implemented as there is a proper alternative (ITSM Designer).

The benefit is that the field could be used by classes which have (perhaps except for cmdbAbstractObject) no ancestor in common.

[Guillaume Lajarige]

The ITSM Designer isn't an alternative to me as you will always have to redefine the field, it's values, it's labels etc. It's the same repetitive tasks.

[Pierre Goiffon]

I tend to agree with Thomas : proper inheritance should be the answer ? I was wondering if you had some use cases of needed multiple parents, but it don't seem to be the case ?

Jeffrey what do you think of Guillaume's proposal to use typologies ?

[Jeffrey Bostoen]

It was meant to also inherit the properties of the field.

Now, I already mentioned the use case: even some parent classes could share a field definition. Perhaps "location" (attribute) is a good example: shared among FunctionalCI and Person, but could also be added to Ticket by some people. Now: if you want to change the OQL filter in any way for all those classes, it's a lot of editing. Imagine just having to adjust it at one place?

[Pierre Goiffon]

Hello,
Thanks for all the explanations.
We'll present your proposal on our next review with the product team !

[Pierre Goiffon]

Combodo internal ref : N°4958

[Pierre Goiffon]

Hello,
The product team reviewed this request.
I'm sorry to say we are not willing to invest time developing this right now.
We might change things in the future, but we would rather develop tools in the ITSM Designer than in iTop core.

[Pierre Goiffon]

Woops, I forgot to mention that for fields we could use composition instead, so having 1-1 relations would be a must. Those relations will be looked at in the coming months (evaluating cost and risk), they then will be planned.

[Molkobain]

In some extensions (molkobain-datacenter-view, molkobain-datacenter-view-extended) I'm adding the same methods / attributes to several XML DM classes.
For instance you can see the nb_u and position_v attributes as well as the IsMounted() and GetEndPositionV() methods here on the Enclosure class, DatacenterDevice class and PDU class.

For now I have to duplicate the XML snippets on each classes which is obvisouly not great.

I was about to propose to introduce PHP traits the same way that we already have the php_parent in classes. But I realised that it would not work with attributes as there are not simple PHP class properties.

So Jeffrey's approach could be a great idea and could be extended to class methods as well.

[Jeffrey Bostoen]

If it's considered for more things... I think the same thing could be beneficial for presentation.

Sometimes a lot of sub classes just have very similar fields. Either for instance the entire presentation of the "details" view; or just a part, could be pre-defined at one place.

[Pierre Goiffon]

Hello,
I had a chat with Guillaume, we have a similar need for extensions that brings multiple nodes at once for the portal : sometimes you don't want those extensions to be added in the default portal but your custom one...
I have an idea but I need to work on it as an experimentation...

[Pierre Goiffon]

As an update, a part of the dev team had a meeting on this subject.
We have multiple ideas, but for now no time to work on the subject :(