Add a generic tagging capability for arbitrary iTop objects

[limosek]

Enhancement details

Problem

iTop has several tag-like features and tagset widgets, but tagging is still fragmented across specific classes and relation models. In practice, this makes it hard to classify arbitrary objects consistently, reuse tags across custom datamodels, and build stable filtering/search workflows on top of tags.

We are looking for a first-class, reusable tagging capability that can be attached to any object class without redefining a dedicated tag field on every class.

Technical background

iTop is datamodel-driven, so a generic solution should not rely on hardcoding a tags field into every object class. Current tag-related mechanisms appear to be class- or relation-specific, and public discussions show limitations around tagset usage in n:n relations.

In particular:

• TagSet / TagSetFieldData is not a universal object-level tagging framework.
• There are known limitations with tagset-like widgets on n:n relations.
• Some workarounds require turning a link class into a standalone class, which suggests the current model is not a generic tagging abstraction.

Proposed solution

Introduce a reusable tagging model with:

• a canonical Tag entity
• a generic association entity such as TagLink or ObjectTag
• support for linking tags to arbitrary objects by class + object id
• UI support to add/remove tags from object detail pages
• filtering/search support by tag
• optional permission/scope handling later

Why this should be generic

• avoids per-class duplication
• works for custom classes as well as core classes
• reduces upgrade risk compared to adding a field everywhere
• makes tag-based search, automation, and reporting consistent

Notes

This is not meant as a per-class TagSet enhancement. The goal is a generic tagging capability at the framework/datamodel level.
Krátká verze, pokud chceš být ostřejší:
Please add a reusable, generic tagging mechanism for arbitrary iTop objects.

Current tagset-based approaches seem class- or relation-specific and do not scale well to a universal object-level tagging model, especially for custom datamodels and n:n relations.

Proposed shape:

• canonical Tag entity
• generic ObjectTag/TagLink association
• object detail UI support
• filtering/search by tag
• basic API support

This should be a framework-level capability, not a hardcoded tag field added to each class.

iTop version (if appropriate)

No response

Are you willing to create (at a later stage) a PR for that?

Yes

Additional information (if needed)

No response

[jbostoen]

Completely agree.

What is also lacking in the current implementation:

• Ability to create new tag from a tag set field. Users needs to go through quite a few extra steps if they decide to come up with
• The way tags are stored on the object (resulting in even a limitation of amount of tags etc.)

Nice to haves:

• Namespacing of the tag (tag category).
• For a tag set, be able to specify which namespace(s) are allowed.
• Colors. Could be set on the tag itself (~ GitHub) or on the tag category (~ Zebrix). Even this could be flexible (e.g. define which color to use in the XML of a new tag set field; or perhaps check if the tag has a color / fall back to tag category color / fall back to some standard color).

For my MFA / Security extension, I actually also shifted to a basic typology class to link "tags" to objects.

[Hipska]

A new category in the datamodel (//class/properties/category) to enable classes which can be tagged would be perfect for this.

However, I'm not opposed to how to currently define Tag fields for classes as it makes sure you can specifically dictate how it is named and where it is placed in the UI. I don't like how they are implemented in the database, resulting in the limitations cited by @jbostoen.

It would already be an improvement if tag field values (so the 'tags' themselves) could be shared by different classes. An option to define a color for each tag value would also be nice for easier distinction when multiple are applied to an object..