Login-Bereich mit (Schnittstelle zu) CiviCRM

Hallo Leute!
Arbeitet jemand mit einem (Mitglieder)Login-Bereich /-Portal mit (Schnittstelle zu) CiviCRM und kann davon berichten?
Viele Grüße
Nina

1 „Gefällt mir“

Wir kennen einige Leute, die so etwas haben, und können euch gern mit diesen in Kontakt bringen. Solche Anwendungsszenarien möchten wir auch beim CiviCamp in Hamburg (3. bis 7. Juni 2024) vorstellen. Wer sich für solche Portal- oder Intranet-Lösungen interessiert, kann sich das schonmal vormerken.

1 „Gefällt mir“

Das ist ja super! Über die Kontakte würde ich mich sehr freuen - und auf das Camp freu ich mich sowieso :smiley:

Ja, da gibt es spannende Lösungen!

Grundsätzlich gibt es ja den Ansatz, dass jedes Mitglied einen Account im CMS bekommt, und damit gemäß einer speziellen Berechtigungsrolle die eigenen Kontaktdaten sehen und ggf. bearbeiten kann.
Vorteil: Einfach zu realisieren, flexibel
Nachteil: Skaliert schlecht - stellt euch vor, eine Organisation mit 4.000 Mitgliedern müsste dann 4.000 user accounts im WordPress oder Drupal verwalten…

Wir empfehlen daher einen token-basierten Login (z.B. mit contact-ID und checksum), wo die Zugangsdaten jeweils per E-Mail an die hinterlegte E-Mail-Adresse gesendet werden.

(hmm - Haben wir dazu nicht hier irgendwo schon was dazu beschrieben??)

Moin Nina,

das geht tatsächlich gut und ist nicht sooo aufwändig unter WordPress.

Was genau möchtest Du eigentlich als „Portal“ haben?

Interessant ist, wenn die Leute Adressänderungen oder sonstige Angaben / Formulareingaben selbst vornehmen sollen. Das geht mit einem CMS-Login sehr gut, sollte aber mit der CRM-Erweiterung „Prevent users from overwriting their record“ abgesichert werden.

Überlege Dir erst, welche Rollen denkbar sind: wahrscheinlich reicht die Abonnentenrolle für Mitglieder aus.

Diese WordPress-Plugins bringen Dich auf den Weg:

  • BuddyPress (eine Art Social Media für Deine Mitglieder)
  • BP Groups CiviCRM Sync (optional: in BuddyPress erstellte Gruppen syncen ins CRM)
  • BuddyPress Members only (optional: erlaubt es Dir, WordPress-Content nur für Mitglieder freizugeben)
  • CiviCRM Profile Sync
  • Login Logout Menu (optional: erstellt einen dynamischen Anmeldebutton im Menü)
  • LoginPress (hiermit kannst Du die Standard-WP-Anmeldemaske bearbeiten, so dass Vor- und Nachname aufgeschlüsselt werden - das ist wichtig für den Sync zwischen WP und CRM)
  • LoginWP (Formerly Peter’s Login Redirect) (optional: Weiterleitung nach der Anmeldung anhand von Rollen)
  • Nav Menu Roles (optional: blende Menüpunkte nach Rollen aus oder ein)

Das sollte, richtig konfiguriert, schon reichen, damit Du ein ordentliches Portal auf die Beine stellen kannst. In WordPress könnte man dann über Shortcodes Spendenseiten, Profile aus dem CRM oder die Übersichtsseite für Mitglieder anzeigen.

Die User können sich über den WordPress-Registrierungsprozess registrieren und werden dann über das Merkmal E-Mail-Adresse mit dem CRM gesynct. Gibt es einen User noch nicht, dann wird ein neuer CRM-Kontakt erstellt (das gilt auch für Spam-Anmeldungen). Wie Detlev schreibt: das muss man im Blick haben. Über den Sync zu Gruppen kann man ein bisschen was mit CiviRules steuern, auch die vergebenen Benutzerrollen.

Liebe Grüße nach Hamburg

Hi @torben.bertram!

Wow, danke für das Kochrezept - also zumindest die Zutatenliste :wink:

Unser Civi läuft auf Drupal - weiß nicht, ob man die Systeme mischen kann / sollte?

Ich werde mich in deinen Post noch weiter einlesen und mich absprechen.

Viele Grüße
Nina

Zwei CMS zu mischen ist vielleicht nicht so gut. In Drupal kann man auch ein Portal bauen, sehr gut geht das mit Webform (erfordert https://www.drupal.org/project/webform_civicrm) für das Einsammeln von Daten und Views zum Anzeigen von Daten.

Ein denkbares Social-Media-Modul wäre Open Social Open Social | Drupal.org, welches mit BuddyPress unter WordPress vergleichbar ist.

Was sind denn Deine genauen Anforderungen an ein Portal / Login-Bereich mit CRM-Schnittstelle?

Dass man mit Drupal sehr schöne Portale bauen kann, kann ich bestätigen. Ich würde aber nicht zu webform_civicrm raten. Das Tool bietet zwar viel Funktionalität, Fehler und Probleme sind aber eher schwer zu beheben. Eine transparente, über APIs abgewickelte Verbindung erleichtert die Wartbarkeit erheblich. Wir vermeiden webform_civicrm daher schon seit langem.

Auch unter Sicherheitsaspekten ist es sicherlich ratsam, das Portal möglichst gründlich vom Backend zu trennen. Der Datenfluss zwischen Portal und CiviCRM sollte in der Hinsicht ausschließlich per API stattfinden, um Angriffsmöglichkeiten auf das Backend zu minimieren.

Unter Drupal kann man mit den SYSTOPIA-Remotetools und dem CMRF-Framework ein solches rein API-basiertes Set-up aufbauen. Die User-Remote-IDs und spezifische Berechtigungen werden zwischen CiviCRM und Drupal synchronisiert. Die Remotetools können - falls bei einer Aktion kein Log-in notwendig sein soll - auch sichere Authentifizierungstoken erzeugen.

Das Portal kann dann auch auf einem separaten System laufen, die Daten werden per REST-API ausgetauscht. Im Frontend werden dabei keine oder fast keine Daten vorgehalten (ggf. das Nötigste für Benutzerkonten). Mit dem CiviProxy von SYSTOPIA ist es zudem möglich, das CiviCRM in einem VPN zu betreiben und trotzdem ein Portal einzurichten, das über das Internet erreichbar ist. Über den CiviProxy werden nur zulässige Anfragen in das VPN und an CiviCRM geleitet.

(Wie wichtig man das findet und wie viel Aufwand einem die Sicherheit wert ist, ist natürlich eine individuelle Entscheidung.)

Zudem kann man mit diesen Tools schon auf viel vorhandene Funktionalität im Kontext von CiviRemote-Portalen zurückgreifen, sei es mit Log-in oder ohne, z.B.

  • de.systopia.remoteevents (Event-Portale)
  • de.systopia.remoteactivity (CiviCRM-Aktivitäten zur Bearbeitung im Portal exponieren, z.B. für Bewerbungen o.ä.)
  • de.systopia.selfservice (eigene Daten bearbeiten)
  • funding (SYSTOPIA-Antragsportal)
  • de.systopia.newsletter (Newsletter abonnieren und Präferenzen verwalten)
  • de.systopia.xcm (Extended Contact Matcher für komplexe Matching-Regeln)
  • Webform und FormProcessor
  • sowie natürlich unzählige Drupal-Module und vieles mehr

Viele Grüße
Martin