#########################################################################
# 																		#
# BNV - Formular (Benutzerverwaltung) Justiz - README					#
#																		#
# (c) ZenIT - Zentraler IT-Dienstleister der Justiz d. Landes Brandenb. #
#																		#
# Autor: 	P. Seidel (ZenIT)											#
# Code:		P. Seidel (ZenIT)											#
# Test:		M. Schöne (ZenIT)											#
#																		#
# Bug-Report:		to P. Seidel (ZenIT)								#
# 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: ###
		Im Bereich row_anwendungen eine neue Checkbox hinzufügen.
		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">

    2.	### HTML - Die Gruppe: ###
		Einen neuen Container <div class="form-grouping hidden" id="gruppeFachXY"> erstellen, der die speziellen Felder für diese Software enthält.

    3.	### JavaScript - Die Logik: ###
		In der Funktion refreshForm() zwei Dinge tun:
			Die Checkbox abfragen: const boxXY = document.getElementById('cbFachXY');
			Die Sichtbarkeit steuern: if (boxXY && boxXY.checked) { showList.push('gruppeFachXY'); }


II.	 Mandanten-Logik (data-areas)
Jedes Element mit dem Attribut data-areas="OLG,SDJ" wird nur angezeigt, wenn in window.MANDANT = '###' der entsprechende Mandant gewählt wurde.

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.
Der "DEBUG"-Mandant: Dieser sollte in jedem data-areas stehen, damit beim Testen immer alles angezeigt wird.


III. wichtige technische Hinweise
Hinweise die aus der Erstellung des Codes ergeben haben und zum Fehlverfahlten des Formulars führen können:
	
	1. Case Sensitivity: JavaScript unterscheidet streng zwischen Groß- und Kleinschreibung. cbDragon ist nicht das gleiche wie cbdragon.
	2. ID vs. Name:
			- id wird für das Styling und JavaScript (Sichtbarkeit) genutzt.
			- 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.


IV. Version-Check
Das Formular prüft beim Start automatisch ob es eine neuere Version von sich gibt. Sollte festgestellt werden, dass:
	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.
	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.

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.
	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)