Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- admin:issues [2022/04/02 05:13]
karpenko [Automatisierte Issues Behebung]
+++ admin:issues [2023/02/25 16:57] (aktuell)
karpenko [Plausichecks hinzufügen]
@@ Zeile 1: / Zeile 1: @@
 ====== Issues ======
-Das Issues System ermöglicht das Erfassen und Bearbeiten von im Rahmen der Arbeit mit FH Complete auftretenden Fehlern.
+Das Issues System ermöglicht das **Erfassen und Bearbeiten** von im Rahmen der Arbeit mit FH Complete auftretenden **Fehlern**.
 Wichtig ist dabei die Unterscheidung zwischen
-  * Fehler: Bestimmt die Art des Fehlers, legt fest, welcher Fehler mit welchen Eigenschaften auftreten kann. Tabelle //system.tbl_fehler//
+  * **Fehler**: Bestimmt die **Art des Fehlers**, legt fest, welcher Fehler mit welchen Eigenschaften auftreten kann. Tabelle //system.tbl_fehler//
-  * Issue: Zu einem konkreten Zeitpunkt in einer konkreten Situation aufgetretener Fehler. Tabelle //system.tbl_issue//
+  * **Issue**: Zu einem **konkreten Zeitpunkt** in einer **konkreten Situation aufgetretener Fehler**. Tabelle //system.tbl_issue//
-Ein issue kann für eine Person oder eine Organisationseinheit auftreten.
+Ein Issue kann für eine **Person** oder eine **Organisationseinheit** auftreten.
 ==== Fehler Monitoring Übersicht ====
-Zur Abarbeitung der Issues existiert eine Fehler Monitoring Übersicht. Hier werden die zuletzt aufgetretenen Issues aufgelistet. Wenn der Issue behoben wurde, kann dieser hier manuell auf "behoben" gesetzt werden.
+Zur Abarbeitung der Issues existiert eine Fehler Monitoring Übersicht. Hier werden die **zuletzt aufgetretenen Issues** aufgelistet. Wenn der Issue behoben wurde, kann dieser hier manuell auf "**behoben**" gesetzt werden.
 {{:admin:fehlermonitoring_uebersicht.png?900|}}
 Ein Issue kann folgende Status haben:
-  * Neu - unbearbeitet, neu aufgetreten
+  * **Neu** - unbearbeitet, neu aufgetreten
-  * In Bearbeitung - Issue von einem Zuständigem/einer Zuständigen zur Behebung vorgemerkt
+  * **In Bearbeitung** - Issue von einem Bearbeiter/einer Bearbeiterin zur Behebung vorgemerkt
-  * Behoben - aufgetretener Issue ist beseitigt
+  * **Behoben** - aufgetretener Issue ist beseitigt
-Ein issue wird in der Übersicht angezeigt, wenn
+Ein Issue wird in der Übersicht angezeigt, wenn
-  * der User für die Organisationseinheit des Issues berechtigt ist (Berechtigung //system/issues_verwalten//) ODER
+  * der User für die **Organisationseinheit des Issues** berechtigt ist (Berechtigung //system/issues_verwalten//) ODER
-  * über eine bestimmte Funktion (z.B. Assistenz) der Organisationseinheit des Issues zugewiesen ist ODER
+  * über eine **bestimmte Funktion** (z.B. Assistenz) der **Organisationseinheit des Issues** zugewiesen ist ODER
-  * über eine bestimmte Funktion (z.B. Assistenz) einem Studiengang zugewiesen ist, in dem die Person des Issues studiert ODER
+  * über eine **bestimmte Funktion** (z.B. Assistenz) einem **Studiengang** zugewiesen ist, in dem die **Person des Issues studiert** ODER
-  * der User oder die Organisationseinheit des Users eine spezielle Zuständigkeit (//system.tbl_fehler_zuständigkeiten//) für einen bestimmten Fehlercode zugewiesen hat.
+  * der **User** oder die **Organisationseinheit des Users** eine **spezielle Zuständigkeit** (//system.tbl_fehler_zuständigkeiten//) für einen **bestimmten Fehlercode** zugewiesen hat.
 Auf der linken Seite der Monitoring Übersicht sind vordefinierte Filter zu finden. So werden je nach Auswahl offene oder erledigte issues angezeigt.
 ==== Automatisierte Issues Behebung ====
-Das Setzen eines Issues auf "Behoben" kann entweder manuell in der Fehler Monitoring Oberfläche oder automatisiert durch einen Job erfolgen. Der Job wird folgendermaßen aufgerufen:
+Das Setzen eines Issues auf "Behoben" kann entweder **manuell** in der Fehler Monitoring Oberfläche oder **automatisiert** durch einen Job erfolgen. Der Job wird folgendermaßen aufgerufen:
-''php index.ci.php/jobs/IssueResolver/run'' für Issues im Core Teil von FH Complete
+  * Für Issues im **Core** Teil von FH Complete: ''php index.ci.php/jobs/IssueResolver/run''
+  * Für in einer **Extension** definierte Issues: ''php index.ci.php/extensions/FHC-Core-Extensionname/jobs/IssueResolver/run''
-''php index.ci.php/extensions/FHC-Core-Extensionname/jobs/IssueResolver/run'' für in einer extension
+Der Job arbeitet alle nicht behobenen Issues im Core oder in der Extension ab und prüft für den Fehlercode des Issues, ob der Issue noch besteht.
-definierte Issues
+Zur automatisierten Behebung muss **pro Fehlercode** definiert werden, **wenn ein aufgetretener Issue** für diesen Fehler als **behoben** gilt. Hierzu sind folgende Schritte notwendig:
+  * Wenn noch nicht erfolgt: **Festlegen des Fehlercodes** sowie //fehler_kurzbz//, //fehlertext//, //fehlertyp_kurzbz// (z.B. //error//, //warning//). Dies erfolgt als SQL entweder im //fehlerupdate.php// File im Core oder in einer Extension.
+  * **Anlegen einer library im //libraries/issues//resolvers Ordner** mit Definition der Prüfung zur Fehlerbehebung. Die library muss die Methode ''checkIfIssueIsResolved($params)'' implementieren. Diese muss ein **success objekt mit "true"**, wenn der Issue **behoben** ist, oder **"false", wenn nicht**, oder ein **error objekt wenn Fehler bei der Prüfung** aufgetreten sind, zurückgeben. Die Methode akzeptiert einen **$params Array**, welcher **zusätzliche, zur Behebung notwendige Parameter** beinhaltet (z.B. //prestudent_id//, wenn der Fehler einen bestimmten Prestudent betrifft). Die Parameter müssen bei Auftreten des Issues (in der jeweiligen Applikation) in die //system.tbl_issue// Tabelle als JSON-Object (Spalte //behebung_parameter//) geschrieben werden. Gemäss Konvention sollte die **library genauso wie der betreffende Fehlercode** benannt werden. Im nachfolgenden Beispiel für eine Issue library wird geprüft, ob das **ZGV Datum eines Studenten in der Zukunft** liegt. Wenn nicht, gilt der Fehler als behoben und es wird success(true) retourniert. Dies hat zur Folge dass der IssueResolver Job den Fehler auf Status "behoben" setzt. Das ZGV Datum ist pro Prestudent gespeichert, daher muss als Parameter die prestudent_id übergeben werden. Dieser Parameter muss beim Schreiben des Issues mitgespeichert werden.
+{{ :admin:issue_library_example.png?520 |}}
+  * **Setzen der Zuordnung des Fehlers zur library im IssueResolver**. Damit der IssueResolver **erkennt**, dass eine **library für die automatische Überprüfung des Issuestatus** existiert, muss im File //IssueResolver.php// das **codeLibMappings Array** ergänzt werden. Der Eintrag hat die Form **'Fehlercode' => 'Library Name'** und weist die library Klasse einem bestimmten Fehlercode zu.
+{{ :admin:issue_resolver_fehler_libraries_zuordnungen.png?420 |}}
-Der Job geht alle nicht behobenen Issues im Core oder in der Extension durch und prüft für den Fehlercode des Issues, ob der Issue noch besteht.
+Nun wird bei Aufruf des IssueResolver Jobs für jeden noch nicht behobenen Issue geprüft, ob der Issue noch besteht, und der Status des Issues wird auf "**behoben**" gesetzt, wenn nicht.
-Zur automatisierten Behebung muss pro Fehlercode definiert werden, wenn ein aufgetretener Issue für diesen Fehler als behoben gilt. Hierzu sind folgende Schritte notwendig:
-  * Wenn noch nicht erfolgt: **Festlegen des Fehlercodes** sowie fehler_kurzbz, fehlertext, fehlertyp_kurzbz (z.B. error, warning). Dies erfolgt als SQL entweder im fehlerupdate.php File im Core oder in einer Extension.
-  * **Anlegen einer library im libraries/issues Ordner** mit Definition der Prüfung zur Fehlerbehebung. Die library muss die Methode ''checkIfIssueIsResolved($params)'' implementieren. Diese muss ein success objekt mit "true", wenn der Issue behoben ist, oder "false", wenn nicht, oder ein error objekt wenn Fehler bei der Prüfung aufgetreten sind, zurückgeben. Die Methode akzeptiert einen $params Array, welcher zusätzliche, zur Behebung notwendige Parameter beinhaltet (z.B. prestudent_id, wenn der Fehler einen bestimmten Prestudent betrifft). Die Parameter müssen bei Auftreten des issues (in der jeweiligen Applikation) in die Issue Tabelle als JSON-Object (Spalte //behebung_parameter//) geschrieben werden. Gemäss Konvention sollte die library genauso wie der betreffende Fehlercode benannt werden. Beispiel für eine Issue library:
-{{ :admin:issue_library_example.png?700 |}}
-Hier wird geprüft, ob das ZGV Datum eines Studenten in der Zukunft liegt. Wenn nicht, gilt der Fehler als behoben und es wird success(true) retourniert. Dies hat zur Folge dass der IssueResolver Job den Fehler auf Status "behoben" setzt. Das ZGV Datum ist pro Prestudent gespeichert, daher muss als Parameter die prestudent_id übergeben werden. Dieser Parameter muss beim Schreiben des Issues mitgespeichert werden.
-  * **Setzen der Zuordnung des Fehlers zur library im IssueResolver**. Damit der IssueResolver erkennt, dass eine library für die automatische Überprüfung des Issuestatus existiert, muss im File IssueResolver.php das codeLibMappings Array ergänzt werden. Der Eintrag hat die Form 'Fehlercode' => 'Library Name' und weist die library Klasse einem bestimmten Fehlercode zu
-Nun sollte bei Aufruf des IssueResolver Jobs für jeden noch nicht behobenen Issue geprüft werden, ob der Issue noch besteht und der Status des Issues entsprechend angepasst werden..
 ==== Fehler Zuständigkeiten ====
-Für die Prüfung und Behebung bestimmter Fehler können einzelne Mitarbeiter bzw. Abteilungen zuständig sein. Hierzu besteht die Möglichkeit, einzelne Fehlercodes einer Person bzw. Organisationseinheit zuzuteilen. In der Fehler Monitoring Übersicht gibt es dazu das Feld "Hauptzuständig". Dieses hat der Wert "Nein" wenn eine Zuständigkeit für einen anderen User als den eingeloggten definiert wurde.
+Für die **Prüfung** und **Behebung** bestimmter Fehler können **einzelne Mitarbeiter** bzw. **Abteilungen** zuständig sein. Hierzu besteht die Möglichkeit, **einzelne Fehlercodes** einer **Person** bzw. **Organisationseinheit** zuzuteilen. In der Fehler Monitoring Übersicht gibt es dazu das Feld "**Hauptzuständig**". Dieses hat der Wert "Nein" wenn eine Zuständigkeit für einen anderen User als den eingeloggten definiert wurde.
 Zur Verwaltung der Zuständigkeiten existiert eine grafische Benutzeroberfläche.
+==== Plausichecks hinzufügen ====
+Plausichecks können verwendet werden, um einen **fehlerhaften Zustand** zu **identifizieren** und **aufzuzeigen**. Hierzu werden ebenfalls Issues produziert, die in der Fehler Monitoring Übersicht aufscheinen.
+Um einen Plausicheck hinzuzufügen, sind folgende Schritte notwendig:
+  * Wenn noch nicht erfolgt: **Festlegen des Fehlercodes** sowie //fehler_kurzbz//, //fehlertext//, //fehlertyp_kurzbz// (z.B. //error//, //warning//). Dies erfolgt als SQL entweder im //fehlerupdate.php// File im Core oder in einer Extension.
+  * **Anlegen einer library im //libraries/issues/plausichecks// Ordner**. Diese muss die //executePlausiCheck// Methode der Elternklasse //PlausiChecker// implementieren. Die Methode muss alle vom Fehler betroffenen Objekte zurückliefern. Der Methode können Paremeter (//$params//) übergeben werden, welche zur Bestimmung des Fehlerzustandes notwendig sind (z.B. Studiengang oder Semester, für welche auf den Fehler geprüft werden soll).
+{{ :admin:issue_plausicheck_plausichecker_example.png?700 |}}
+Im obigen Beispiel wird geprüft, ob es Studierende gibt, für die kein Sponsionsdatum eingetragen ist.
+Die Prüfung kann auf Studiensemester und Studiengang eingeschränkt werden (//$params//).
+Zurückgegeben werden Ids und Organisationseinheiten aller betroffenen Studierenden. Zusätzlich werden //prestudent_id// und //abschlusspruefung_id// zurückgegeben, da diese im Fehlertext des Issues aufscheinen sollen (optional, //fehlertext_params//). Die //abschlusspruefung_id// wird auch in den //resolution_params// (optional) übergeben, da der Issue automatisch behoben werden soll und dafür die Id der Abschlussprüfung notwendig ist.
+Die eigentliche Prüfung des Fehlers (//getDatumSponsionFehlt//) ist in die //PlausicheckLib// ausgelagert. Da für die automatische Behebung die gleiche Logik wiederverwendet wird, ist dies hier sinnvoll.
+  * **Setzen der Zuordnung des Fehlers zur library im PlausiIssueProducer**. Damit der IssueProducer **erkennt**, dass eine **library für den Plausicheck** existiert, muss im File //PlausiIssueProducer.php// das **fehlerLibMappings Array** ergänzt werden. Der Eintrag hat die Form **'Fehlerkurzbezeichnung' => 'Library Name'** und weist die library Klasse einer bestimmten Fehlerbezeichnung zu.
+==== Plausichecks durchführen ====
+  * **PlausiIssueProducer starten**: Der //PlausiIssueProducer// Job **produziert Issues für alle definierten Plausichecks**. Dieser kann als Job Controller im Core oder in der [[developer:extensions|extension]] angelegt werden und muss den //PlausiIssueProducer_Controller// erweitern:
+{{ :admin:issue_plausicheck_issueproducer_example.png?600 |}}
+Obige Abbildung zeigt einen //PlausiIssueProducer// in einer [[developer:extensions|extension]], der Plausichecks für den Fehler //UhstatStaatsbuergerschaftFehlt// durchführt.
+  * **Plausicheck GUI**: Hier können Plausichecks **manuell durchgeführt** werden. So kann geprüft werden, welche Fehler momentan bestehen, ohne Jobs starten zu müssen. Hierbei werden keine Issues produziert, es wird nur ausgegeben, ob und für welche Objekte ein Fehler besteht.
+{{ :admin:issue_plausicheck_gui.png?700 |}}
+Beispiel der Durchführung von Plausichecks für den Studiengang Biomedical Engineering in der GUI

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge