Hallo zusammen,
Ich wollte nur eben die Informationen hinterlegen über die wir bereits diskutiert haben.
Aktuell fehlt uns noch im Admin-Bereich die Möglichkeit zentrale zeitgesteuerte Aufgaben zu sehen und diese zu aktivieren/deaktivieren oder neu anzulegen. Ein löschen solcher zentralen Aufgaben soll erst einmal nicht möglich sein um zu verhindern dass essenzielle Events ausversehen verschwinden.
Für das Thema Probealarmierung ist eine solche Aufgabenverwaltung bereits implementiert. Ich werde versuchen dies auch für die core Jobs umzusetzen.
Ja, die „CORE“-relevanten Jobs müssen beim Serverstart neu angelegt werden und dürfen nicht überschrieben / verändert oder geslöscht werden. Ich frag mich grade, ob wir die fest im Code hinterlegen sollten, oder ob wir die nicht auch in der Datenbank verwalten. Wenn wir in Zukunft neue / weitere Jobs für den core benötigen sollte das nicht jedesmal eine Änderung am Code mit sich bringen, oder?
Ich würde die Verwaltung Mal ohne „löschen“ Button auf der Oberfläche implementieren. Die Funktionalität ist aber im beakend bereits drin
und die Core-Jobs kommen auch schon per Definition aus der Datenbank? Oder werden die aktuell noch im Code angelegt beim Serverstart?
Außer der Job für Stefan kommt alles nur aus der db.
Das migrations-script legt aber aktuell nur die Tabelle in der DB an und fügt die Jobs die vorher im Code von dir angelegt wurden nicht in die Tabelle ein. Deshalb sind die Ausgaben bei Michael weg.
D.h. wir müssten noch ein „Migrations“-Script hinzufügen für
und dann hätten wir das gleiche Verhalten wie vorher?
Ja. Und für 5 Minuten.
Das waren die drei meines Wissens nach.
Und für Stefans auch gleich. Dann kann ich es aus dem Code nehmen.
Dann kann ich gerne das Migrations Script schreiben, wenn wir den DEV-Branch gemerged haben.
Das hört sich gut an. Dann warte auf den dev-branch bevor ich weiter implementieren.
@BoxSon : Ich habe mir jetzt gerade mal den Code für das IsTest-Flag angeschaut. Wird das flag nicht in der DB gespeichert?
Dann tu ich mich schwer mit der Anzeige in der Oberfläche.
Da hast Du Recht! Das mache ich noch schnell.
Habs eingecheckt in feature_rules_for_alarmings
https://github.com/BoxSo/ALARMiator-Server/commit/689b5d0db068aa726b8b3ee6f6f5ba40ae7ec767
Du meinst den " [feature_request_test_alarm]"
Wir müssen Dringend den DEV-Branch einführen.
Ich muss hier ständig von unterschiedlichsten Branches die sachen einsammeln.
Das ist nicht gut
Hab die verwendung des isTest-flags jetzt doch gleich auf dem Probealarmierung-Branch gemacht.
Ich würde aber gerne die OperationSourceConnector auf testalarm stehen lassen. Dann weis man das es aus dem umfeld Probealarmierung gekommen ist und nicht vom Admin als einfacher event ausgelöst worden ist.
aber dann bitte „core_testalarm“ oder „core_generic_testalarm“ oder so. „TestAlarm“ ist zu generell finde ich.
OK. Hab das jetzt so umgebaut und gepushed.
Super, habs mir schon angesehen. Passt. Nun müssen wir mal schauen, dass wir alles in einen DEV-Branch bekommen.
