API-Zugangsdaten sollen einmal am Netzwerkgerät hinterlegt und von passenden Checks automatisch verwendet werden können. Konfigurationspakete sollen dabei weiterhin gemeinsame Schwellenwerte vorgeben, ohne dass dafür die gesamte Check-Konfiguration je Gerät angepasst werden muss. Auch VMware ESXi und vCenter sollen die am Netzwerkgerät gespeicherten Benutzernamen und Passwörter für passende Checks verwenden können. Gemeinsame Check-Einstellungen wie Schwellenwerte sollen dabei weiterhin aus dem Konfigurationspaket übernommen werden.

Eine Option, damit man die nicht registrierten Nebenstellen ggf. ausschließen kann. Entweder alle auf einmal, oder einzeln

Der Netzwerkfreigaben-Check soll Freigabe- und NTFS-Rechte gemeinsam auswerten und nach dem tatsächlich möglichen Zugriff alarmieren können. Die Einstellung soll über Konfigurationspakete für viele Geräte nutzbar sein, ohne einzelne Freigabenamen als Ausnahmen pflegen zu müssen.

Alle möglichen Eingabefeld-Typen. siehe custom fields von Geräten.

Das Fenster eines Rings wirkt heute als "sofort bei beginn starten", nicht als Verteilung. Das kann unter Umständen die Netzwerkbandbreite des Endkunden überlasten. Vorschlag: Ein Zeitfenster in dem die Updates verteilt auf den Geräten eines Standortes gestartet werden.

Eigene Feldwerte in Berichtsvorlagen aufnehmen können. Den bereits vorhandenen CSV-Export hier herauslassen.

Je Auswahlwert Farbe und Symbol festlegen; am Feld und in der Geräteliste anzeigen.

Geräte markieren und einen Feldwert gemeinsam setzen oder leeren. Andere Feldwerte bleiben erhalten.

FelderPflichtstatus, maximale Länge und Formatvorgaben je Feld einstellen können.

Zeitpunkt, Verursacher und Änderung nachvollziehen können – auch bei Änderungen durch API, Automationen und Checks.

Kundenwerte auf Geräte vererben, dort einzeln überschreiben und wieder zur geerbten Vorgabe zurückkehren können.

Standortbezogene Angaben direkt am Standort erfassen, anzeigen und bearbeiten können.

Je Feld festlegen, wer Werte sehen oder ändern darf. Die Rechte müssen auch für Automationen, API, Suche und Exporte gelten.

Werte eigener Felder sollen über die globale Suche auffindbar sein, beispielsweise ein dokumentierter Switchport oder eine Inventarnummer. Angezeigt wird das zugehörige Gerät beziehungsweise der Kunde. Geschützte Feldwerte müssen ihre Zugriffsbeschränkungen auch in der Suche behalten.

Automationen sollen als eigene Treffergruppe in der globalen Suche erscheinen. Bei Eingabe eines Kundennamens sollen außerdem dessen Geräte auffindbar sein. Bei mehr Treffern als angezeigt führt „Alle anzeigen“ in eine entsprechend gefilterte Liste. Ergebnisse müssen die Zugriffsrechte des angemeldeten Benutzers beachten.

Wir wünschen uns eine Funktion zur Berichtserstellung für unsere Kunden – optional auch direkt für die jeweiligen Anwender –, wenn ein System seit mehr als einer variablen Anzahl von Tagen, z. B. 30 Tagen, keinen Neustart durchgeführt hat. Die Ermittlung könnte aus unserer Sicht über die Systemstartzeit / letzte Boot-Zeit erfolgen. Ziel: Benutzer und IT-Verantwortliche sollen dafür sensibilisiert werden, Systeme regelmäßig neu zu starten. Dadurch können insbesondere Probleme im Zusammenhang mit Windows Updates, ausstehenden Neustarts und allgemeiner Systemstabilität reduziert werden. Optional wäre es hilfreich, den Zeitraum kundenindividuell konfigurieren zu können.

Eine Möglichkeit um während dem Rollout den vollen Funktionsumfang der MACs ab Tag 1 nutzen zu können, selbst wenn die erste Fernwartung erst Tage später erfolgt.

Um zu steuern, ob zum Beispiel Endkunden auch Beta-Funktionen nutzen können sollen.

Es wäre schön wenn man sehen könnte wie lange der Benutzer schon seine Maus und Tastatur nicht mehr bewegt hat. Dann hat man ein Überblick darüber ob der Nutzer noch da ist.

Eine Integration von Nextcloud Talk wäre als zusätzlicher Benachrichtigungskanal sehr sinnvoll. Daher wäre es wünschenswert, Octoja-Benachrichtigungen direkt an Nextcloud Talk bzw. definierte Talk-Räume senden zu können.