readme.md aktualisiert
This commit is contained in:
121
readme.md
121
readme.md
@@ -1,63 +1,60 @@
|
|||||||
#########################################################################
|
# BNV - Formular (Benutzerverwaltung) Justiz - README
|
||||||
# #
|
**_(c) ZenIT - Zentraler IT-Dienstleister der Justiz d. Landes Brandenburg_**
|
||||||
# BNV - Formular (Benutzerverwaltung) Justiz - README #
|
|
||||||
# #
|
**Autor:** P. Seidel (ZenIT)
|
||||||
# (c) ZenIT - Zentraler IT-Dienstleister der Justiz d. Landes Brandenb. #
|
**Code:** P. Seidel (ZenIT)
|
||||||
# #
|
**Test:** M. Schöne (ZenIT)
|
||||||
# Autor: P. Seidel (ZenIT) #
|
|
||||||
# Code: P. Seidel (ZenIT) #
|
**Bug-Report:** to P. Seidel (ZenIT)
|
||||||
# Test: M. Schöne (ZenIT) #
|
**Feature Request:** to P. Seidel (ZenIT)
|
||||||
# #
|
|
||||||
# Bug-Report: to P. Seidel (ZenIT) #
|
**Release-Notes:** release.md
|
||||||
# Feature Request: to P. Seidel (ZenIT) #
|
|
||||||
# #
|
|
||||||
# Release-Notes: release.md #
|
## I. neue Anwendung
|
||||||
# #
|
Wenn eine neue Anwendung (z.B. "Fachverfahren XY") hinzufügt werden soll, müssen immer diese drei Orte angepasst werden:
|
||||||
#########################################################################
|
|
||||||
|
1. **HTML - Die Checkbox:**
|
||||||
I. neue Anwendung
|
Im Bereich `row_anwendungen` eine neue Checkbox hinzufügen.
|
||||||
Wenn eine neue Anwendung (z.B. "Fachverfahren XY") hinzufügt werden soll, müssen immer diese drei Orte angepasst werden:
|
**Wichtig:** `data-areas` setzen, damit nur die richtigen Mandanten sie sehen. (siehe 2. Mandanten-Logik)
|
||||||
|
**Beispiel:** `<input type="checkbox" id="cbFachXY" data-areas="OLG,SDJ">`
|
||||||
1. ### HTML - Die Checkbox: ###
|
2. **HTML - Die Gruppe:**
|
||||||
Im Bereich row_anwendungen eine neue Checkbox hinzufügen.
|
Einen neuen Container `<div class="form-grouping hidden" id="gruppeFachXY">` erstellen, der die speziellen Felder für diese Software enthält.
|
||||||
Wichtig: data-areas setzen, damit nur die richtigen Mandanten sie sehen. (siehe 2. Mandanten-Logik)
|
Ggf. `data-areas` setzen falls die Sichtbarkeit zusätzlich eingeschränkt werden soll.
|
||||||
|
3. **JavaScript - Die Logik:**
|
||||||
Beispiel: <input type="checkbox" id="cbFachXY" data-areas="OLG,SDJ">
|
In der Funktion `refreshForm()` zwei Dinge tun:
|
||||||
|
1. _Die Checkbox abfragen:_ `const boxXY = document.getElementById('cbFachXY');`
|
||||||
2. ### HTML - Die Gruppe: ###
|
2. _Die Sichtbarkeit steuern:_ `if (boxXY && boxXY.checked) { showList.push('gruppeFachXY'); }`
|
||||||
Einen neuen Container <div class="form-grouping hidden" id="gruppeFachXY"> erstellen, der die speziellen Felder für diese Software enthält.
|
|
||||||
|
## II. Mandanten-Logik (data-areas)
|
||||||
3. ### JavaScript - Die Logik: ###
|
Jedes Element mit dem Attribut `data-areas="OLG,SDJ"` wird nur angezeigt, wenn in `window.MANDANT = '###'` der entsprechende Mandant eingetragen wurde.
|
||||||
In der Funktion refreshForm() zwei Dinge tun:
|
|
||||||
Die Checkbox abfragen: const boxXY = document.getElementById('cbFachXY');
|
**Wichtig:** Wenn ein übergeordneter Container (z.B. eine Zeile oder eine Gruppe) ein `data-areas` Attribut hat, sind alle Felder darin automatisch mit gesperrt, auch wenn sie selbst kein Attribut haben.
|
||||||
Die Sichtbarkeit steuern: if (boxXY && boxXY.checked) { showList.push('gruppeFachXY'); }
|
**Der `DEBUG`-Mandant:** Dieser sollte in jedem `data-areas` stehen, damit beim Testen immer alles angezeigt wird.
|
||||||
|
|
||||||
|
## III. wichtige technische Hinweise
|
||||||
II. Mandanten-Logik (data-areas)
|
_Hinweise die sich aus der Erstellung des Codes ergeben haben und zum Fehlverfahlten des Formulars führen können:_
|
||||||
Jedes Element mit dem Attribut data-areas="OLG,SDJ" wird nur angezeigt, wenn in window.MANDANT = '###' der entsprechende Mandant gewählt wurde.
|
1. **Case Sensitivity:** JavaScript unterscheidet streng zwischen Groß- und Kleinschreibung. `cbDragon` ist nicht das gleiche wie `cbdragon`.
|
||||||
|
2. **ID vs. Name:**
|
||||||
Wichtig: Wenn ein übergeordneter Container (z.B. eine Zeile oder eine Gruppe) ein data-areas Attribut hat, sind alle Felder darin automatisch mit gesperrt, auch wenn sie selbst kein Attribut haben.
|
- `id` wird für das Styling und JavaScript (Sichtbarkeit) genutzt.
|
||||||
Der "DEBUG"-Mandant: Dieser sollte in jedem data-areas stehen, damit beim Testen immer alles angezeigt wird.
|
- `name` wird für die PDF-Ausgabe genutzt (das ist das Label im PDF).
|
||||||
|
3. **Checkboxen im PDF:** Einzelne Checkboxen (wie das Headset) werden immer automatisch mit "Ja" übersetzt, wenn kein fester `value` im HTML steht.
|
||||||
|
4. **Datum:** Datumsfelder werden beim Auslesen für das PDF automatisch von YYYY-MM-DD in DD.MM.YYYY umgewandelt.
|
||||||
III. wichtige technische Hinweise
|
|
||||||
Hinweise die aus der Erstellung des Codes ergeben haben und zum Fehlverfahlten des Formulars führen können:
|
## IV. Version-Check
|
||||||
|
### Version-Logik
|
||||||
1. Case Sensitivity: JavaScript unterscheidet streng zwischen Groß- und Kleinschreibung. cbDragon ist nicht das gleiche wie cbdragon.
|
Die Versionen zum Vergleichen sind **immer** ganze Zahlen.
|
||||||
2. ID vs. Name:
|
Das bedeutet eine Version 1.2 ist 12 bei der Prüfung (1.2 = 12). Wenn im folgenden von -2 Versionen gesprochen wird, ist somit die Versionsnummer hinter dem **.** gemeint!
|
||||||
- id wird für das Styling und JavaScript (Sichtbarkeit) genutzt.
|
### Version-Check
|
||||||
- name wird für die PDF-Ausgabe genutzt (das ist das Label im PDF).
|
Das Formular prüft beim **Start** automatisch ob es eine neuere Version von sich gibt. Sollte festgestellt werden, dass:
|
||||||
3. Checkboxen im PDF: Einzelne Checkboxen (wie das Headset) werden immer automatisch mit "Ja" übersetzt, wenn kein fester value im HTML steht.
|
1. die Version **-1** alt ist, erscheint am Anfang eine rote Box mit dem Hinweis, dass es eine neuere Version gibt mit entsprechenden Download-Link. _Ein Arbeiten ist weiterhin möglich_.
|
||||||
4. Datum: Datumsfelder werden beim Auslesen für das PDF automatisch von YYYY-MM-DD in DD.MM.YYYY umgewandelt.
|
2. die Version **-2** oder älter, erscheint am Anfang eine rote Box mit _eindringlichen_ Hinweis, dass es eine neuere Version gibt mit entsprechenden Download-Link. _Ein Arbeiten ist **NICHT** mehr möglich_.
|
||||||
|
### Version-Dokumentation
|
||||||
|
Die Versionssteuerung erfolgt an **2 Stellen**.
|
||||||
IV. Version-Check
|
1. Im Formular muss die Version gepflegt werden.
|
||||||
Das Formular prüft beim Start automatisch ob es eine neuere Version von sich gibt. Sollte festgestellt werden, dass:
|
2. Auf der Intranet-Seite **justiz-info muss** `version_check.js` angepasst werden.
|
||||||
1. die Version -1 alt ist, erscheint am Anfang eine rote Box mit dem Hinweis, dass es eine neuere Version gibt mit entsprechenden Download-Link. Ein Arbeiten ist weiterhin möglich.
|
#### Version hinterlegen
|
||||||
2. die Version -2 oder älter, erscheint am Anfang eine rote Box mit eindringlichen Hinweis, dass es eine neuere Version gibt mit entsprechenden Download-Link. Ein Arbeiten ist NICHT mehr möglich.
|
1. Im Formular `APP_VERSION_ID` entsprechend anpassen (es werden nur ganze Zahlen akzeptiert [Version 1.7 = 17])
|
||||||
|
2. in `version_check.js` nur die Versionsnummer eintragen, z.B. `17`
|
||||||
Die Versionssteuerung erfolgt an 2 Stellen. Im Formular muss die Version gepflegt werden. Auf der Intranet-Seite justiz-info muss version_check.js angepasst werden.
|
3. `version_check.js` auf die Intranet-Seite (justiz-info) als Media hochladen, vorhandene Datei ersetzen (_Hr. Seidel Ansprechpartner_)
|
||||||
1. Im Formular APP_VERSION_ID entsprechend anpassen (es werden nur ganze Zahlen akzeptiert [Version 1.7 = 17])
|
|
||||||
2. in version_check.js nur die Versionsnummer eintragen, z.B. 17
|
|
||||||
3. version_check.js auf die Intranet-Seite als Media hochladen, vorhandene Datei ersetzen (Hr. Seidel Ansprechpartner)
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user