Zum Inhalt springen

Änderungen von Dokument Digitale Mitgliederverwaltung

Zuletzt geändert von Daniel Herrmann am 2026/02/22 21:17
Von Version Icon 31.1 Icon
bearbeitet von Daniel Herrmann
am 2025/08/22 17:53
Änderungskommentar: Es gibt keinen Kommentar für diese Version
Auf Version Icon 28.1 Icon
bearbeitet von Daniel Herrmann
am 2025/08/22 15:25
Änderungskommentar: Es gibt keinen Kommentar für diese Version

Zusammenfassung

Details

Icon Seiteneigenschaften
Inhalt
... ... @@ -19,7 +19,7 @@
19 19  
20 20  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:
21 21  
22 -(% class="wrapped" style="text-decoration: none;" %)
22 +(% style="text-decoration: none;" %)
23 23  |=(((
24 24  Signaturtyp
25 25  )))|=(((
... ... @@ -69,7 +69,6 @@
69 69  
70 70  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:
71 71  
72 -(% class="wrapped" %)
73 73  |=(% scope="col" %)(((
74 74  Dokumenten-Typ
75 75  )))|=(% scope="col" %)(((
... ... @@ -319,7 +319,6 @@
319 319  
320 320  Im zweiten Schritt wird nun ein oder mehrere personalisierte Dokumente erstellt. Hier gibt es eine Entscheidungsmatrix:
321 321  
322 -(% class="wrapped" %)
323 323  |=(% scope="col" %)(((
324 324  Remote / Lokal
325 325  )))|=(% scope="col" %)(((
... ... @@ -375,8 +375,7 @@
375 375  
376 376  Im dritten Schritt müssen eine oder mehrere Parteien das Dokument unterschreiben. Wie viele Parteien ist abhängig vom Dokument. So muss beispielsweise der Mitgliedsantrag nur vom werdenden Mitglied unterschrieben werden, während das Schlüsselausgabeformular vom ausgebenen Funktionär und dem Mitglied unterschrieben werden muss. Analog zur Erstellung des Dokuments wird hier unterschieden, ob das Dokument zuhause unterschrieben werden kann oder ob es vor Ort im Makerspace passiert.
377 377  
378 -(% class="wrapped" %)
379 -|=(((
376 +(% class="" %)|=(((
380 380  Remote / Lokal
381 381  )))|=(((
382 382  Schriftformerfordernis
... ... @@ -385,7 +385,7 @@
385 385  )))|=(((
386 386  Beschreibung
387 387  )))
388 -|(((
385 +(% class="" %)|(((
389 389  Remote
390 390  )))|(((
391 391  Nein
... ... @@ -394,7 +394,7 @@
394 394  )))|(((
395 395  Unterschrift über DocuSeal. Parteien werden nacheinander per Mail zur Unterschrift aufgefordert
396 396  )))
397 -|(((
394 +(% class="" %)|(((
398 398  Remote
399 399  )))|(((
400 400  Ja
... ... @@ -403,7 +403,7 @@
403 403  )))|(((
404 404  Das Mitglied muss das Dokument ausdrucken, **handschriftlich** unterschreiben und in den Makerspace mitbringen.
405 405  )))
406 -|(((
403 +(% class="" %)|(((
407 407  Lokal
408 408  )))|(((
409 409  Nein
... ... @@ -415,7 +415,7 @@
415 415  * Direkt auf dem Tablet in Docuseal ([[Docuseal In-Person Signing>>url:https://www.docuseal.com/resources/sign-documents-in-person||shape="rect"]])
416 416  * PDF erzeugen, in der App unterschreiben, PDF danach in Paperless hochladen
417 417  )))
418 -|(((
415 +(% class="" %)|(((
419 419  Lokal
420 420  )))|(((
421 421  Ja
... ... @@ -430,7 +430,6 @@
430 430  
431 431  Egal welcher Prozess angewandt wird, das Dokument muss am Ende in Paperless eingelesen und mit den Meta-Daten (siehe unten) versehen werden. Hier gibt es drei verschiedene Varianten:
432 432  
433 -(% class="wrapped" %)
434 434  |=(% scope="col" %)(((
435 435  Signatur über
436 436  )))|=(% scope="col" %)(((
... ... @@ -537,7 +537,6 @@
537 537  
538 538  Daraus ergeben sich vier verschiedene Kombinationen (Workflows), die nachstehend genauer beschrieben sind.
539 539  
540 -(% class="wrapped" %)
541 541  |=(% scope="row" %)(((
542 542  Workflow
543 543  )))|=(% scope="col" %)(((
... ... @@ -603,7 +603,7 @@
603 603  
604 604  === {{id name="DigitaleMitgliederverwaltung-Fall2:Digital+Makerspace"/}}Fall 2: Digital + Makerspace ===
605 605  
606 -In diesem Fall kann die Unterschrift digital erfolgen, allerdings findet die Unterschrift im Makerspace statt. Beispiel hier ist die Ausgabe eines Schlüssels und das Schlüsselausgabeformular.
601 +In diesem Fall kann die Unterschrift ebenfalls digital erfolgen, allerdings findet die Unterschrift im Makerspace statt. Beispiel hier ist die Ausgabe eines Schlüssels und das Schlüsselausgabeformular.
607 607  
608 608  Wir können nicht davon ausgehen, dass alle Personen ein mobiles Endgerät dabei haben, mit dem sie E-Mails abrufen und Unterschriften leisten können. Außerdem ist die Unterschrift Voraussetzung dafür, dass der Schlüssel auch tatsächlich eingebunden wird, die Unterschrift ist also mittig in einem Prozess eingebunden und erfordert ein unmittelbares Feedback ähnlich einer handschriftlichen Unterschrift.
609 609  
... ... @@ -613,62 +613,14 @@
613 613  
614 614  {{confluence_drawio border="true" diagramName="Fall 2 Ablaufdiagramm" simpleViewer="false" links="auto" tbstyle="top" lbox="true" diagramWidth="1138" height="499" revision="2"/}}
615 615  
616 -Die einzelnen Schritte hierbei sind:
617 -
618 -1. Ein autorisierter User meldet sich am Tablet an einer App an, entweder per Makerspace Login (Keycloak) oder per Keyfob. Dort hat der Benutzer dann mehrere Optionen, beispielsweise die Ausgabe eines Schlüssels. Dies erfordert irgendwo im Prozess, dass direkt vor Ort ein Dokument unterschrieben werden muss.
619 -1. Tablet sendet im Namen des angemeldeten Benutzers eine Anfrage ans Backend. Die Anfrage wird vom Backend verarbeitet. Danach...
620 -11. Speichert das Backend die Anfrage als Signature Request in der Datenbank
621 -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).
622 -11. (((
623 -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:\\
624 -
625 -{{expand}}
626 -{{code language="json"}}
627 -[
628 - {
629 - "id": 430,
630 - "uuid": "3845d527-ea14-402a-bd05-e85cd4b28a68",
631 - "name": "Vorname Nachname",
632 - ...
633 - "role": "Mitglied",
634 - "embed_src": "https://sign.makerspace-darmstadt.de/s/mMUEBY6Knz1vap"
635 - },
636 - {
637 - "id": 431,
638 - "uuid": "04cbbf45-e3eb-4956-b104-01c0315adc94",
639 - "name": null,
640 - ...
641 - "role": "Verein",
642 - "embed_src": "https://sign.makerspace-darmstadt.de/s/k5gvGuBjW5fkb1"
643 - }
644 -]
645 -{{/code}}
646 -{{/expand}}
647 -)))
648 -1. Die beteiligten Personen unterschreiben direkt auf dem Tablet.
649 -1. Nachdem alle Parteien unterschrieben haben informiert Docuseal das Backend über ein Webhook. Das Backend markiert den Prozess als abgeschlossen und führt gegebenenfalls interne Schritte aus (Berechtigungen für ein User anlegen oder ähnliches). Der Vorgang kann auf dem Tablet direkt weitergeführt werden.
650 -1. Das Backend erstellt ein NATS Event mksp.backend.signature.completed, welches dann in N8n einen Workflow auslöst
651 -1. N8n lädt das von allen Parteien unterschriebene Dokument von Docuseal herunter
652 -1. N8n lädt das Dokument zu Paperless hoch. Dort wird es wie alle anderen Dokumente verarbeitet. Das Post Consumption Script (siehe unten) scannt das Dokument auf einen MKSP QR Code
653 -1. Wird ein MKSP QR Code gefunden passieren zwei Dinge:
654 -11. Die Paperless Meta Daten werden automatisch zugewiesen.
655 -11. Bei Bedarf (Konfiguration im QR Code) wird ein N8n Webhook ausgelöst
656 -1. (Optional): Wurde im vorherigen Schritt über den Webhook ein N8n Workflow ausgelöst, kann dieser nun weitere Schritte unternehmen (beispielsweise Vikunja Tasks erzeugen, Mails verschicken, oder ähnlich)
657 -
658 658  === {{id name="DigitaleMitgliederverwaltung-Fall3:Handschriftlich+Remote"/}}Fall 3: Handschriftlich + Remote ===
659 659  
660 -In diesem Fall wird der Prozess durch einen Benutzer **remote ausgelöst, benötigt allerdings die Schriftform.** In diesem Fall wird dem Benutzer ein vorausgefülltes und mit QR Code versehenes Dokument zum Download angeboten, welches dann heruntergeladen, ausgedruckt, unterschrieben und eingereicht werden muss.
613 +ToDo
661 661  
662 -**Beispiele**: Einweisungszettel für reine Online-Einweisungen
663 -
664 -{{confluence_drawio border="true" diagramName="Fall 3 Ablaufdiagramm_" simpleViewer="false" links="auto" tbstyle="top" lbox="true" diagramWidth="1159" height="467" revision="2"/}}
665 -
666 666  === {{id name="DigitaleMitgliederverwaltung-Fall4:Handschriftlich+Makerspace"/}}Fall 4: Handschriftlich + Makerspace ===
667 667  
668 668  ToDo
669 669  
670 -{{confluence_drawio border="true" diagramName="Fall 4 Ablaufdiagramm" simpleViewer="false" links="auto" tbstyle="top" lbox="true" diagramWidth="1138" height="499" revision="1"/}}
671 -
672 672  = {{id name="DigitaleMitgliederverwaltung-PaperlessNGX"/}}Paperless NGX =
673 673  
674 674  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**.
... ... @@ -698,7 +698,6 @@
698 698  **Dokumenten-Typen**: Einem Dokument wird exakt ein Typ zugewiesen. Dokumenten Typen sind im Prinzip einfache Gruppen. Für die Mitgliederverwaltung sind die Gruppen gemäß der folgenden Tabelle festgelegt, können aber natürlich bei Bedarf erweitert werden. Neben einem Namen haben die Dokumente einen Match String. Kommt dieser eindeutig (exakter Match) irgendwo im Dokument vor, wird der Typ automatisch zugewiesen.
699 699  \\
700 700  
701 -(% class="wrapped" %)
702 702  |=(% scope="col" %)(((
703 703  Name
704 704  )))|=(% scope="col" %)(((
... ... @@ -783,7 +783,6 @@
783 783  {
784 784   "payload": {
785 785          "timestamp": "YYYY-MM-DDTHH:mm:ss",
786 - "uuid": "260171c3-c71c-4da2-b13e-bf1386fe9eac",
787 787   "correspondent": "Daniel Herrmann (#250)",
788 788   "type": "mksp-doc-sepamandat",
789 789   "tags": [
... ... @@ -796,7 +796,7 @@
796 796  }
797 797  {{/code}}
798 798  
799 -Die beiden Einträge **payload** und **sig** sind **Pflichtfelder**. Innerhalb der Payload müssen der **timestamp** **und die UUID** **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.
744 +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.
800 800  
801 801  === {{id name="DigitaleMitgliederverwaltung-Signatur"/}}Signatur ===
802 802  
Icon Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -202867226
1 +202867128
URL
... ... @@ -1,1 +1,1 @@
1 -https://wiki.makerspace-darmstadt.de/spaces/PROJ/pages/202867226/Digitale Mitgliederverwaltung
1 +https://wiki.makerspace-darmstadt.de/spaces/PROJ/pages/202867128/Digitale Mitgliederverwaltung