Änderungen von Dokument Digitale Mitgliederverwaltung

Zusammenfassung

• Seiteneigenschaften (1 geändert, 0 hinzugefügt, 0 gelöscht)

Details

Seiteneigenschaften

Inhalt

...	...	@@ -23,7 +23,7 @@
23	23
24	24	Kurz gesagt: Die EES ist schnell und unkompliziert, aber unsicher und nur für risikofreie Vorgänge geeignet. Die FES ist technisch sicherer, rechtlich belastbarer und für wichtige, aber formfreie Vereinbarungen ideal. Die QES ist rechtlich vollwertig wie eine handschriftliche Unterschrift und für alle Schriftformerfordernisse zwingend notwendig. Zusammenfassung:
25	25
26		-(% class="wrapped" style="text-decoration:none" %)
	26	+(% class="wrapped" style="text-decoration: none;" %)
27	27	|=(((
28	28	Signaturtyp
29	29	)))|=(((
...	...	@@ -61,8 +61,8 @@
61	61	Mehrfaktor, über einen zugelassenen Vertrauensdienstleister
62	62	)))
63	63
	64	+\\
64	64
65		-
66	66	{{confluence_tip title="Zusammenfassung"}}
67	67	Für uns im Makerspace bedeutet das, dass wir die EES und FES (über DocuSeal) einsetzen können. Wir haben keine Partnerschaft mit einem Anbieter, der die QES und damit die Schriftformerfordernis abdecken würde, sodass wir alle Dokumente, für die die Schriftform erforderlich ist, weiterhin handschriftlich unterschreiben lassen.
68	68	{{/confluence_tip}}
...	...	@@ -74,14 +74,14 @@
74	74	Am Dienstag, den 12.08.2025 fand hierzu ein Workshop statt, bei dem Vertreter des IT Teams, der Mitgliederverwaltung sowie des Vorstands teilgenommen haben. Dabei wurden die Ziele erläutert und definiert, ebenfalls haben eine Übersicht der bestehenden Dokumenten-Typen erstellt, mit denen wir im Verein heute hantieren. Für jedes Dokument wurde dann evaluiert, ob es in Zukunft komplett digitalisiert werden kann oder ob beispielsweise aus Haftungsgründen die Schriftform und damit eine handschriftliche Unterschrift weiterhin notwendig ist. Die folgende Tabelle gibt einen Überblick:
75	75
76	76	(% class="wrapped" %)
77		-|=(((
	77	+|=(% scope="col" %)(((
78	78	Dokumenten-Typ
79		-)))|=(((
	79	+)))|=(% scope="col" %)(((
80	80	Vollständig
81	81	digitalisieren
82		-)))|=(((
	82	+)))|=(% scope="col" %)(((
83	83	Prozess heute
84		-)))|=(((
	84	+)))|=(% scope="col" %)(((
85	85	Notwendige Änderungen
86	86	)))
87	87	|(((
...	...	@@ -164,7 +164,7 @@
164	164	)))|(((
165	165	Notwendig für Funktionäre, Einweisende, und so weiter.
166	166
167		-Ist ein Blanko-Formular, welches ausgefüllt, eingeworfen und abgeheftet wird.
	167	+Ist ein Blanko-Formular, welches ausgefüllt, eingeworfen und abgeheftet wird.
168	168	Danach wird ein Flag für das jeweilige Mitglied gesetzt, dass die Erklärung abgegeben wurde.
169	169	)))|(((
170	170	**Vollständig digital**. Vorstand oder Mitgliederverwaltung löst den Prozess über das Profil des Mitglieds aus (Button auf Homepage), danach digital weiter.
...	...	@@ -317,13 +317,13 @@
317	317	Im zweiten Schritt wird nun ein oder mehrere personalisierte Dokumente erstellt. Hier gibt es eine Entscheidungsmatrix:
318	318
319	319	(% class="wrapped" %)
320		-|=(((
	320	+|=(% scope="col" %)(((
321	321	Remote / Lokal
322		-)))|=(((
	322	+)))|=(% scope="col" %)(((
323	323	Schriftformerfordernis
324		-)))|=(((
	324	+)))|=(% scope="col" %)(((
325	325	Beispiel
326		-)))|=(((
	326	+)))|=(% scope="col" %)(((
327	327	Beschreibung
328	328	)))
329	329	|(((
...	...	@@ -361,7 +361,7 @@
361	361	)))|(((
362	362	Einweisungszettel Vor-Ort Einweisung
363	363	)))|(((
364		-Dokument wird über eine Docuseal One-Off Submission erzeugt und als PDF auf das Tablet heruntergeladen.
	364	+Dokument wird über eine Docuseal One-Off Submission erzeugt und als PDF auf das Tablet heruntergeladen.\\
365	365	)))
366	366
367	367	{{error title="Docuseal Lizenz"}}
...	...	@@ -420,7 +420,7 @@
420	420	Einweisungszettel Vor-Ort Einweisung
421	421	)))|(((
422	422	Auf dem Makerspace Tablet wird das Dokument vor Ort ausgedruckt (AirPrint oder CUPS) und **handschriftlich** unterschrieben.
423		-
	423	+\\
424	424	)))
425	425
426	426	=== Ablegen und Verarbeiten ===
...	...	@@ -428,11 +428,11 @@
428	428	Egal welcher Prozess angewandt wird, das Dokument muss am Ende in Paperless eingelesen und mit den Metadaten (siehe unten) versehen werden. Hier gibt es drei verschiedene Varianten:
429	429
430	430	(% class="wrapped" %)
431		-|=(((
	431	+|=(% scope="col" %)(((
432	432	Signatur über
433		-)))|=(((
	433	+)))|=(% scope="col" %)(((
434	434	Paperless Ingest
435		-)))|=(((
	435	+)))|=(% scope="col" %)(((
436	436	Ablauf
437	437	)))
438	438	|(((
...	...	@@ -515,7 +515,7 @@
515	515	Im Wesentlichen teilt sich die Architektur in zwei Zonen, die **öffentliche** und die **interne** Zone:
516	516
517	517	* **Paperless** ist das maßgebliche System, welches ausschließlich **intern** erreichbar ist. Es enthält alle Dokumente und somit sehr viele Mitglieder-Daten. Weiterhin ist es auf ein Teil der Infrastruktur im Makerspace (NAS, Drucker, Scanner) angewiesen, sodass es im Netzwerk des Makerspaces laufen muss. Aus Sicherheitsgründen ist Paperless ausschließlich im lokalen Netzwerk des Makerspaces oder per VPN erreichbar.
518		-* Alle den **Mitgliedern gegenüber sichtbare Systeme (Homepage, Backend, ...) sind öffentlich **und auf einem gemieteten Server beim deutschen Anbieter Hetzner gehostet. [[Details dazu finden sich im Wiki>>doc:xwiki:IN.IT Infrastruktur.Public Server Infrastruktur.WebHome]]. Die meiste bestehende Automatisierung wird aktuell im Backend durchgeführt, ist dort allerdings in Python Logic fest einprogrammiert. Die meiste Logik soll in Zukunft über N8n realisiert werden.
	518	+* Alle den **Mitgliedern gegenüber sichtbare Systeme (Homepage, Backend, ...) sind öffentlich **und auf einem gemieteten Server beim deutschen Anbieter Hetzner gehostet. [[Details dazu finden sich im Wiki>>confluencePage:page:IN.Public Server Infrastruktur]]. Die meiste bestehende Automatisierung wird aktuell im Backend durchgeführt, ist dort allerdings in Python Logic fest einprogrammiert. Die meiste Logik soll in Zukunft über N8n realisiert werden.
519	519
520	520	Für die Kommunikation zwischen beiden Zonen kommt eine **Event Queue** zum Einsatz, wir nutzen hier NATS. NATS wird ebenfalls **auf dem öffentlichen Server installiert. **Der Makerspace selbst ist nur über eine reguläre DSL Leitung an das Internet angebunden, sodass wir hier keine hohe Verfügbarkeit voraussetzen können. Durch die Installation der NATS Services auf dem öffentlichen Server können die dort laufenden Services wie das Backend jederzeit (auch wenn die Internet-Verbindung im Makerspace nicht zur Verfügung steht) die Events veröffentlichen. Die Events werden dann bis zu 7 Tage in der NATS EventQueue persistent gespeichert, und nach Wiederherstellung der Verbindung abgearbeitet.
521	521
...	...	@@ -537,12 +537,12 @@
537	537	(% class="wrapped" %)
538	538	|=(% scope="row" %)(((
539	539	Workflow
540		-)))|=(((
	540	+)))|=(% scope="col" %)(((
541	541	Schriftform erforderlich
542		-)))|=(((
	542	+)))|=(% scope="col" %)(((
543	543	Lokal / Remote
544	544	)))
545		-|=(((
	545	+|=(% scope="row" %)(((
546	546	Fall 1: Digital Remote
547	547	)))|(((
548	548	Nein
...	...	@@ -549,7 +549,7 @@
549	549	)))|(((
550	550	Remote
551	551	)))
552		-|=(((
	552	+|=(% scope="row" %)(((
553	553	Fall 2: Digital Makerspace
554	554	)))|(((
555	555	Nein
...	...	@@ -556,7 +556,7 @@
556	556	)))|(((
557	557	Lokal
558	558	)))
559		-|=(((
	559	+|=(% scope="row" %)(((
560	560	Fall 3: Handschriftlich Remote
561	561	)))|(((
562	562	Ja
...	...	@@ -563,7 +563,7 @@
563	563	)))|(((
564	564	Remote
565	565	)))
566		-|=(((
	566	+|=(% scope="row" %)(((
567	567	Fall 4: Handschriftlich Makerspace
568	568	)))|(((
569	569	Ja
...	...	@@ -617,7 +617,7 @@
617	617	11. Speichert das Backend die Anfrage als Signature Request in der Datenbank
618	618	11. Erstellt eine "Submission" in DocuSeal. Diese basiert auf einem Template und enthält so viele Daten wie möglich schon vorausgefüllt. Mindestens aber enthält die Submission den signierten QR Code (siehe unten).
619	619	11. (((
620		-Die URL für das Dokument werden als Antwort des API Requests an das Tablet zurück geschickt. Dies enthält die Embed-URL, die direkt auf dem Tablet angezeigt werden kann. Beispiel:
	620	+Die URL für das Dokument werden als Antwort des API Requests an das Tablet zurück geschickt. Dies enthält die Embed-URL, die direkt auf dem Tablet angezeigt werden kann. Beispiel:\\
621	621
622	622	{{expand}}
623	623	{{code language="json"}}
...	...	@@ -704,7 +704,7 @@
704	704
705	705	= Paperless NGX =
706	706
707		-Das Herzstück der digitalen Mitgliederakte bildet Paperless NGX. Es wird im Makerspace lokal betrieben und ist daher nur aus dem Netzwerk des Makerspaces oder [[per VPN>>doc:xwiki:IN.IT Infrastruktur.IT im Makerspace.[HOWTO] Makerspace VPN.WebHome]] erreichbar. Der Zugang zu Paperless ist über OpenID Connect an [[doc:xwiki:IN.IT Infrastruktur.Services.Keycloak.WebHome]] gekoppelt, Zugang besteht nur für Mitglieder der Gruppen **Vorstand** und **Mitgliederverwaltung**.
	707	+Das Herzstück der digitalen Mitgliederakte bildet Paperless NGX. Es wird im Makerspace lokal betrieben und ist daher nur aus dem Netzwerk des Makerspaces oder [[per VPN>>confluencePage:page:IN.[HOWTO] Makerspace VPN]] erreichbar. Der Zugang zu Paperless ist über OpenID Connect an [[confluencePage:page:IN.Keycloak]] gekoppelt, Zugang besteht nur für Mitglieder der Gruppen **Vorstand** und **Mitgliederverwaltung**.
708	708
709	709	== Paperless Übersicht ==
710	710
...	...	@@ -812,9 +812,9 @@
812	812
813	813	**Aus diesem Grund wird auf jedes Dokument einen spezieller QR Code aufgedruckt**. Der QR code wird vom Post-Consume Script verwendet um die Metadaten in Paperless zuzuordnen. Weiterhin können Daten übermittelt werden, die dann mittels Webhook an N8n übermittelt werden und dort im Workflow verwendet werden können. Der Aufbau orientiert sich an dem Aufbau eines **JSON Web Tokens (JWT).**
814	814
815		-=== (% style="color:var(--ds-text-accent-purple-bolder,#352c63)" %)Barcode erzeugen(%%) ===
	815	+=== (% style="color:var(--ds-text-accent-purple-bolder,#352c63);" %)Barcode erzeugen(%%) ===
816	816
817		-(% style="color:var(--ds-text-accent-purple-bolder,#352c63)" %)Der Prozess zur Erzeugung eines QR Codes ist wie folgt:
	817	+(% style="color:var(--ds-text-accent-purple-bolder,#352c63);" %)Der Prozess zur Erzeugung eines QR Codes ist wie folgt:
818	818
819	819	* **Payload (Daten) festlegen**. Einige Werte sind verpflichtend, andere können nach Bedarf optional hinzugefügt werden.
820	820	* JWT erzeugen und signieren. der JWT besteht aus drei Teilen:
...	...	@@ -829,7 +829,7 @@
829	829
830	830	=== Body ===
831	831
832		-Die folgenden Claims sind im Body verfügbar.
	832	+Die folgenden Claims sind im Body verfügbar:
833	833
834	834	|=(((
835	835	Claim
...	...	@@ -879,7 +879,6 @@
879	879	)))|(((
880	880	Typ des Dokuments basierend auf der unten definierten Liste.
881	881	)))
882		-|mode|String|✅️ |Kann entweder "digital" oder "manual" sein und bestimmt, ob N8n den unterschriebenen Vertrag ans Backend meldet.
883	883	|(((
884	884	(% class="code" %)
885	885	(((
...	...	@@ -934,25 +934,25 @@
934	934
935	935	Die Implementierung für die Erzeugung und das Validieren erfolgt in Python. Dies hat den Hintergrund, dass sowohl unser Backend als auch Paperless NGX (und damit das Post-Consumption Script) in Python implementiert ist. Es gibt verschiedene Libraries, die betrachtet wurden:
936	936
937		-|=(((
	936	+|=(% scope="col" %)(((
938	938	Name
939		-)))|=(((
	938	+)))|=(% scope="col" %)(((
940	940	CVE
941		-)))|=(((
	940	+)))|=(% scope="col" %)(((
942	942	Github
943		-)))|=(((
	942	+)))|=(% scope="col" %)(((
944	944	GH⭐
945		-)))|=(((
	944	+)))|=(% scope="col" %)(((
946	946	Letztes Release
947		-)))|=(((
	946	+)))|=(% scope="col" %)(((
948	948	Offene Issues
949		-)))|=(((
	948	+)))|=(% scope="col" %)(((
950	950	Dokumentation
951		-)))|=(((
	950	+)))|=(% scope="col" %)(((
952	952	Qualität Dokumentation
953		-)))|=(((
	952	+)))|=(% scope="col" %)(((
954	954	In Backend vorhanden?
955		-)))|=(((
	954	+)))|=(% scope="col" %)(((
956	956	In Paperless vorhanden?
957	957	)))
958	958	|(((
...	...	@@ -1025,11 +1025,11 @@
1025	1025
1026	1026	=== PDF417 Code ===
1027	1027
1028		-Als Format für den Code wurde PDF417 ausgewählt, da dieser mehr Platz und Fehlerkorrektur bietet. Weiterhin gibt es eine einfach zu nutzende Library für Python (Erzeugung) und PDF417 wird von (% style="color:var(--ds-text-accent-purple-bolder,#352c63); text-decoration:none" %)ZXING unterstützt, welches in Paperless eingebettet ist. Ein solcher Barcode sieht beispielsweise so aus:
	1027	+Als Format für den Code wurde PDF417 ausgewählt, da dieser mehr Platz und Fehlerkorrektur bietet. Weiterhin gibt es eine einfach zu nutzende Library für Python (Erzeugung) und PDF417 wird von (% style="text-decoration: none;color:var(--ds-text-accent-purple-bolder,#352c63);" %)ZXING unterstützt, welches in Paperless eingebettet ist. Ein solcher Barcode sieht beispielsweise so aus:
1029	1029
1030		-(% style="color:var(--ds-text-accent-purple-bolder,#352c63); text-decoration:none" %)[[image:attach:barcode.jpg||height="250"]]
	1029	+(% style="text-decoration: none;color:var(--ds-text-accent-purple-bolder,#352c63);" %)[[image:attach:barcode.jpg||height="250"]]
1031	1031
1032		-(% style="color:var(--ds-text-accent-purple-bolder,#352c63); text-decoration:none" %)Daraus kann dann eine Base64 basierte Repräsentation berechnet werden, die einfach in Docuseal hochgeladen werden kann.
	1031	+(% style="text-decoration: none;color:var(--ds-text-accent-purple-bolder,#352c63);" %)Daraus kann dann eine Base64 basierte Repräsentation berechnet werden, die einfach in Docuseal hochgeladen werden kann.
1033	1033
1034	1034	=== Referenz-Implementierung ===
1035	1035