Änderungen von Dokument Digitale Mitgliederverwaltung

Zusammenfassung

• Seiteneigenschaften (1 geändert, 0 hinzugefügt, 0 gelöscht)
• Objekte (1 geändert, 0 hinzugefügt, 0 gelöscht)
  • Confluence.Code.ConfluencePageClass[0]

Details

Seiteneigenschaften

Inhalt

...	...	@@ -65,6 +65,8 @@
65	65
66	66	= {{id name="DigitaleMitgliederverwaltung-Anforderungen/Workshop"/}}Anforderungen / Workshop =
67	67
	68	+== {{id name="DigitaleMitgliederverwaltung-WelcheDokumentehabenwir?"/}}Welche Dokumente haben wir? ==
	69	+
68	68	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:
69	69
70	70	|=(% scope="col" %)(((
...	...	@@ -286,6 +286,14 @@
286	286	\\
287	287	)))
288	288
	291	+== {{id name="DigitaleMitgliederverwaltung-WorkflowBeschreibung"/}}Workflow Beschreibung ==
	292	+
	293	+Basierend auf diesen Dokumententypen ergeben sich einige verschiedene Workflows, die im Folgenden genauer beschrieben werden:
	294	+
	295	+1. **Personalisierbar**, **ohne Schriftformerfordernis** - Das Formular wird on demand über Docuseal zur Unterschrift bereit gestellt und automatisch in Paperless hinzugefügt. Optional kann eine Aktion im Backend (bestimmte Flags, ...) und/oder andere Aktionen in über N8n (Vikunja, Listmonk, ...) ausgeführt werden.
	296	+1. **Personalisierbar, mit Schriftformerfordernis** - Das Formular wird on demand erzeugt und ausgedruckt und handschriftlich unterschrieben. Dann wird es eingescannt und zu Paperless hinzugefügt. Optional kann eine Aktion im Backend (bestimmte Flags, ...) und/oder andere Aktionen in über N8n (Vikunja, Listmonk, ...) ausgeführt werden.
	297	+1. **Nicht Personalisierbar, mit Schriftformerfordernis** - Wir können das Formular stand heute nicht personalisieren (kein QR Code). In diesem Fall wird es eingescannt und muss manuell bearbeitet werden.
	298	+
289	289	= {{id name="DigitaleMitgliederverwaltung-TechnischeÜbersicht"/}}Technische Übersicht =
290	290
291	291	== {{id name="DigitaleMitgliederverwaltung-VorhandeneKomponenten"/}}Vorhandene Komponenten ==
...	...	@@ -443,6 +443,52 @@
443	443
444	444	Aus diesem Grund nutzen wir einen speziellen QR Code in einem für den Makerspace spezifischen Format, welches nachstehend detailliert beschrieben wird.
445	445
	456	+{{code language="json"}}
	457	+{
	458	+ "payload": {
	459	+        "timestamp": "YYYY-MM-DDTHH:mm:ss",
	460	+ "correspondent": "Daniel Herrmann (#250)",
	461	+ "type": "mksp-doc-sepamandat",
	462	+ "tags": [
	463	+ "tag1",
	464	+ "tag2"
	465	+ ],
	466	+"storage_path": "Mitgliederverwaltung"
	467	+ },
	468	+ "sig": "signature over the entire payload block"
	469	+}
	470	+{{/code}}
	471	+
	472	+Die beiden Einträge **payload** und **sig** sind **Pflichtfelder**. Innerhalb der Payload muss der **timestamp** **vorhanden** sein, alle anderen Felder sind optional, jedoch muss mindestens eins angegeben werden. Der QR Code kann dann - insbesondere bei der Digitalen Unterschrift oder bei Workflows, wo die Formulare ohnehin on demand erzeugt werden bereits mit allen Daten bestückt werden. In Paperless gibt es dann ein Postconsume Script, welches den QR Code ausliest, die Signatur prüft und - falls die Signatur korrekt ist - automatisch die Meta-Daten übernimmt.
	473	+
	474	+=== {{id name="DigitaleMitgliederverwaltung-Signatur"/}}Signatur ===
	475	+
	476	+Die Signatur wird kryptographisch mit Hilfe asymmetrischen Verschlüsselung erzeugt. Wir erzeugen ein RSA 2048 Key Pair. Der öffentliche Schlüssel steht Paperless zur Verfügung, sodass Paperless die Signaturen verifizieren kann. Der private Teil des Schlüssels wird von den Makerspace-Systemem verwendet, welche die Formulare erzeugen. Im Detail:
	477	+
	478	+* **Key-Pair**: 2048 bit Schlüssellänge, RSA, 65537 Exponent
	479	+* **Signatur**: SHA256 Signatur, PKCS1v15 Padding
	480	+* (((
	481	+**Payload**: Als Payload wird nur der Inhalt der Payload verwendet, als **JSON String ohne Whitespaces, byte encoded in UTF-8.** Das oben genannte Beispiel würde die Signatur über den folgenden String erstellen:
	482	+\\
	483	+
	484	+{{code language="json"}}
	485	+{"payload":{"correspondent":"Daniel Herrmann (#250)","type":"SEPA Mandat","tags":["tag1","tag2"]},"timestamp":"YYYY-MM-DDTHH:mm:ss","sig":"this-would-be-the-signature-appended-to-the-data"}
	486	+{{/code}}
	487	+
	488	+
	489	+Als Referenz, die in Python wäre der Input der Signatur:
	490	+\\
	491	+
	492	+{{code language="python"}}
	493	+import json
	494	+
	495	+input_data = {'payload': {'correspondent': 'Daniel Herrmann (#250)', 'type': 'SEPA Mandat', 'tags': ['tag1', 'tag2']}, 'timestamp': 'YYYY-MM-DDTHH:mm:ss', 'sig': 'this-would-be-the-signature-appended-to-the-data'}
	496	+signature_data = json.dumps(input_data, separators=(',', ':')).encode('utf-8')
	497	+{{/code}}
	498	+)))
	499	+
	500	+\\
	501	+
446	446	== {{id name="DigitaleMitgliederverwaltung-TechnischesSetup"/}}Technisches Setup ==
447	447
448	448	Owner: zwei Owner

Confluence.Code.ConfluencePageClass[0]

Id

...	...	@@ -1,1 +1,1 @@
1		-202866865
	1	+202866879

URL

...	...	@@ -1,1 +1,1 @@
1		-https://wiki.makerspace-darmstadt.de/spaces/PROJ/pages/202866865/Digitale Mitgliederverwaltung
	1	+https://wiki.makerspace-darmstadt.de/spaces/PROJ/pages/202866879/Digitale Mitgliederverwaltung