cmdb.objects_by_relation Archivierte Beziehungen herausfiltern

TYzer

Hallo,

durch den letzten Umzug wurden vor allem viele Monitore zwischen Mitarbeitern getauscht, was auch alles in i-doit eingetragen ist. Zur Kontrolle sollen Mitarbeiter zukünftig regelmäßig selbst prüfen und bestätigen können, ob ihre zugewiesene Hardware noch aktuell ist. Wir verwenden dazu die jsonrpc.

Über cmdb.objects_by_relation bekommen wir zwar alle zugewiesenen Objekte zu einem Nutzer, aber auch jene, die ehemals zugewiesen waren und jetzt archiviert sind, weil sie jemand anderem zugewiesen sind.
disp-106 ist dem Nutzer aktuell wirklich zugeordnet, disp-053 dagegen gehört mittlerweile einem anderen Nutzer, das ist aus diesen Daten aber nicht ersichtlich.

"296053": {
    "data": {
        "id": 296053,
        "title": "disp-053 is used by Max Mustermann",
        "cmdb_status_title": null,
        "related_object": 290863,
        "related_title": "disp-053",
        "related_type": 22,
        "related_type_title": "Monitore",
        "related_cmdb_status_title": "In Betrieb",
        "master": 290863,
        "slave": 283320,
        "type": 60,
        "type_title": "Beziehungen"
    },
    "children": false
},
"303244": {
    "data": {
        "id": 303244,
        "title": "disp-106 is used by Max Mustermann",
        "cmdb_status_title": null,
        "related_object": 296625,
        "related_title": "disp-106",
        "related_type": 22,
        "related_type_title": "Monitore",
        "related_cmdb_status_title": "In Betrieb",
        "master": 296625,
        "slave": 283320,
        "type": 60,
        "type_title": "Beziehungen"
    },
    "children": false
}

Schaut man sich dann die Relations des betreffenden Monitors an, bekommt man ebenfalls auch beide Nutzer.

"296053": {
    "data": {
        "id": 296053,
        "title": "disp-053 is used by Max Mustermann",
        "cmdb_status_title": null,
        "related_object": 283320,
        "related_title": "Max Mustermann",
        "related_type": 53,
        "related_type_title": "Personen",
        "related_cmdb_status_title": "In Betrieb",
        "master": 290863,
        "slave": 283320,
        "type": 60,
        "type_title": "Beziehungen"
    },
    "children": false
},
"303378": {
    "data": {
        "id": 303378,
        "title": "disp-053 wird benutzt von Melanie Mustermann",
        "cmdb_status_title": null,
        "related_object": 288259,
        "related_title": "Melanie Mustermann",
        "related_type": 53,
        "related_type_title": "Personen",
        "related_cmdb_status_title": "In Betrieb",
        "master": 290863,
        "slave": 288259,
        "type": 60,
        "type_title": "Beziehungen"
    },
    "children": false
}

Die Relation IDs dürften wohl fortlaufend vergeben werden, daher ließe sich nun zwar schließen, dass der Eintrag mit der ID 303378 der aktuellere ist und 296053 archiviert ist. Dennoch ist das ein API-Call mehr, der ggf. nicht notwendig wäre, wenn der erste Call bereits eindeutig mitteilen würde, ob die Relation noch aktiv oder schon archiviert ist.
Gibt es etwas, das ich übersehen habe?

MartinV

@TYzer said:

Gibt es etwas, das ich übersehen habe?

Du zeigst leider nur die Antworten, nicht die Abfragen; daher die Frage: hast Du den "status"-Parameter mit Wert 2 (= normal) in der Abfrage cmdb.objects_by_relation.readByID/readByConst verwendet?

TYzer

Danke, das scheint das zu sein, was ich brauche. Ist das irgendwo dokumentiert? Ich habe in dieser Dokumentation nachgeschaut, aber objects_by_relation wird dort gar nicht weiter aufgeführt.

MartinV

Moin!

Ich kenne nur die Dokumentation gemäß dem Motto "Use the source, Luke"; womit ich hier den Quellcode der PHP Client API meine.

leobaer

Hi

Ich denke der Zustand
(siehe https://kb.i-doit.com/display/de/Lebens-+und+Dokumentationszyklus)
ist ein so elementares Konzept von i-doit, dass es an vielen Stellen einfach nicht mehr explizit erwähnt wird.

Du hast dieses Verhalten z.B. auch auch im Report Manager

Leo