User Synchronisation via Feeds mit zusätzlichen Feldern (Edited)

hi martin
schau mal hier

http://drupal.org/project/sharepoint

vg+stf

Hallo Martin,

da es sich um eine "Plattform zur internen Kommunikation" handelt, zieht sich SharePoint die Benutzerdaten vielleicht aus einer AD (ActiveDirectory)?
Wenn ja, kannst du die Benutzerdaten ganz einfach via LDAP synchronisieren.

Wenn nein, brauchst du vielleicht ein kleines Modul, dass die MS-SQL-Datenbank ausliest und dann die Benutzer synchronisiert. EIn klein wenig Arbeit, aber lösbar.

Bei Möglichkeit 1, einfach mal auf drupal.org nach LDAP-Modulen suchen.
Bei Möglichkeit 2, ein paar Tutorials zur Modulprogrammierung machen.

Grüße

Michael

Hallo ihr zwei. Danke für eure Antworten auf diese wahrscheinlich ziemlich spezifische Frage :) Also erst einmal zu dem SharePoint Modul. Das scheint die Möglichkeit zu bieten Dinge in Feeds oder Views umzusetzen aber leider nicht die Daten auch in anderer Art und Weise weiter zu verwenden. Außerdem habe ich Angst, dass es nicht wieter entwickelt wird und ich dann vor einem Code Berg stehe, den ich nicht durchblicken kann.

Die zweite Möglichkeit hört sich gut an und ich werde das in jedem Fall überprüfen - kommt eben darauf an, ob es in einem solchen ActiveDirectory liegt.

Ich hatte mir auch überlegt einfach die MS SQL Tabelle in einer SQL Tabelle zu übersetzen (sollte doch möglich sein oder - leider habe ich mich BISHER noch nicht damit beschäftigt). Dann könnte ich einfach einen Abgleich stattfinden lassen. Dazu müsste ich aber mehr Informationen dazu finden, was alles für DB Einträge nötig sind um Benutzer manuell anzulegen - denn in irgendeiner Weise müssen ja auch Benutzerrollen, Passwörter etc abgespeichert werden.

Hallo Martin,

bitte nicht die DB direkt abgleichen. Macht dir nur Stress. Dann lieber ein kleines Modul, das entweder die Daten direkt aus MS SQL zieht oder den Umweg über CSV geht, die Nutzerdaten in ein $account-Objekt legt und mittels user_save() (siehe: http://api.drupal.org/api/drupal/modules!user!user.module/function/user_save/7) abspeichert.

Haben wir so aus LDAP schonmal für ein Intranet realisiert, weil das LDAP-Modul damals nicht so wollte wie wir - durchaus lösbar.

Grüße

Michael

Okay, ich bringe jetzt gerade in Erfahrung ob die Daten in einem AD liegen. Könntest du mir den Weg schriftlich mal gaanz grob skizzieren? Also im wesentlichen beinhalten die Datensätze die Stammdaten sowie erweiterte Informationen und einfache Gruppenbezeichnungen, welche später die Zugangsberechtigung in Drupal steuern sollen.

... soll ich skizzieren?

Bei uns liegen die Daten in einem AD.
Über einen Cron in DRUPAL wird das Modul einmal nächtlich aufgerufen, stellt via LDAP eine Verbindung zur AD her, lädt alle Benutzer und vergleicht die Daten, die via LDAP kommen mit den DRUPAL-Benutzern: neue werden angelegt, geänderte werden geändert, fehlende werden in DRUPAL gesperrt.
Fertig.

Wow :D einfach wie effektiv ^^ Danke. Sobald ich die entsprechenden Infos habe werde ich mich daran versuchen und dich mal unterrichten sobald es läuft ^^ Danke für die Hilfe.

Vielleicht auch hilfreich um direkt den MS SQL Server anzusprechen http://drupal.org/project/sqlsrv

Der MS SQL-Server - Treiber ist nur dann einzusetzen, wenn die Drupal Datenbasis auf einer MS SQL-Datenbank liegt und das ist nur dann wirklich sinnvoll, wenn DRUPAL auf einem IIS betrieben wird.
Und diese Konstellation ist zwar möglich (siehe: http://www.microsoft.com/web/drupal) sollte aber sehr gut überlegt werden, da nicht alle Module mit der MS SQL - Datenbank klarkommen.

Wir haben ein Unternehmensintranet für den IIS mit MS SQL auf Basis von Drupal aufgebaut, mussten aber bei einigen Modulen noch Hand anlegen. So ist z.B. das Standard DATE-Field nicht für den MS SQL kompatibel - hier muss im ISO-Format gearbeitet werden. Außerdem gibt es Probleme bei der Konvertierung von UTF-8 nach ISO und viele mehr.

Also - theoretisch möglich, in der Praxis aber viel Extraaufwand von nöten.

Michael

Ich bin ehrlich gesagt froh, dass DAS nicht der Fall ist. Ich bin ja Azubi zum Mediengestalter. Auf die Anforderungen die dadurch an mich entstehen würden bin ich nicht vorbereitet ^^ Es ist aber glücklicherweise so, dass dieser Kunde lediglich seine Kunden, bzw Mitgliederdaten (es ist ein Verband) in Sharepoint pflegt. Von dort muss ich sie eben irgendwie regelmäßig in Drupal einpflegen, weil die komplette Datenpflege in Sharepoint passieren wird. Zuvor hatte der ehemalige Azubi, der wesentlich fitter als ich war eine Schnittstelle geschrieben, mit der er die Daten aus der MS SQL DB in eine MySQL DB geschrieben hat und diese dann 1:1 in eine Kundendatenbank des CMS WebEdition übertragen hat - das ist bei WebEdition vollkommen problemlos möglich, die Kunden werden am Ende wie erwartet im Backend angezeigt und sind verwaltbar. Dieser weg wurde mir ja hier für Drupal nicht empfholen. Ich kann mir auch gut vorstellen, dass das für Probleme sorgt. Ich hoffe jetzt fest auf das LDAP Modul und werde mich damit versuchen. Wenn das klappt, dann habe ich eine wesentliche Anforderung erfüllt.

Uh da habe ich den Mund wohl ziemlich voll genommen. Ich glaube ich könnte noch genauere Tipps zum Einrichten des Moduls gebrauchen. Ich will ja nichts anderes machen als regelmäßig alle Benutzer neu zu importieren - inklusive Passwort etc.

Beim Einrichten des Servers werden einige Daten abgefragt, die (bzw deren Funktion) ich nicht interpretieren kann. Im Bereich "LDAP User to Drupal User Relationship" werden folgende Daten abgefragt:

AuthName attribute,
AccountName attribute,
Email attribute,
Email template,
Persistent and Unique User Attribute,
Expression for user DN. Required when "Bind with Users Credentials" method selected. ,
PHP to transform Drupal login username to LDAP UserName attribute.
Testing Drupal Username

Vor allem der vorletzte Punkt verwirrt mich - denn ich will ja nicht meine Drupal User in das AD Exportieren sondern umgekehrt. Im besten Fall hat Drupal keinen außer Lesezugriff auf dieses Directory - dann kann auch nichts schief gehen.

Und wie wird das mit den Benutzerberechtigungen geregelt? Also wie kann ich die importieren?

Was mich erschreckt ist deine Aussage "inklusive Passwort"...

LDAP wird dir das Passwort des Benutzers aus der AD nicht geben. Hier wird deine Reise enden.
Du kannst neue Passwörter vergeben oder du kannst später die Authentifizierung am AD-Server selber via LDAP erfolgen lassen. Aber wenn das keine Lösung ist, solltest du doch einen anderen - einfachereren Weg wählen:
Wenn ich oben lese, dass die Benuter früher in einer mySQL-DB vorlagen - vielleicht kann man die als Datenquelle nutzen?

Michael

hmm. eher schwierig, da diese nicht mehr auf einem aktuellen stand ist. ich nehme an, dass das benutzerpasswort in den benutzerdatensätzen nicht als passwort gespeichert wird, da es automatisch aus anderen benutzerspezifischen daten erstellt wird. würde das das problem entschärfen ^^ ?

Andernfalls wäre es sicher auch eine Lösung nur die anderen benutezrdaten auszulesen - passwörter könnte man dann ja sicher beim erstmaligen import eines benutzers neu versenden an die angegebene email adresse.

Hallo Martin,

bevor wir hier weiter ins Blaue raten, mach doch einfach mal folgendes:
1. Kläre welche Daten für einen Dupalbenutzer angelegt werden sollen (neben User, Mail und PW)
2. Kläre wo diese Daten in welchem Format zur Verfügung stehen oder gestellt werden können (DB, AD, Export - CSV, Excel, ...) und auch welche Daten es dort jeweils gitb.

... wenn wir das genau wissen, dann kann ich dir sagen, wie ich auf die Quelle zugreifen würde und wie ich diese Daten dann in Drupal importieren würde.

Grüße

Michael

Hallo Micha ,

also ich habe hier jetzt glücklicherweise für klare Linien sorgen können. Ich habe mir jetzt einfach eine routine geschrieben um das ganze in eine MySQL Tabelle zu übertragen. Dort stehen alle Daten in Klartext die ich brauche und von dort möchte ich Sie in Drupal importieren.

Ich muss etliche zusätzliche Profilfelder anlegen, z.T. mit Text, z.T. mit Zahlen. Am liebsten wäre es mir, wenn ich die ganze Sache einfach mit einer PHP Funktion in die Datenbank schreiben könnte. Die User Roles könnte ich vorher anlegen, dann wüsste ich was ich für die jeweilige UserRole in die User Tabelle eintragen muss. Auch die zusätzlichen Felder könnte ich vorher anlegen. Da entsteht ja für jedes eine einzelne Tabelle in der Datenbank, ich wüsste also wo ich die Daten jeweils rein schreiben muss.

Wenn es ein Modul gibt, was diese Aufgabe (den Import von verschiedenen Daten aus einer MySQL Tabelle in die User Tabelle und in die Tabellen für die zusätzlichen Felder) erledigen kann wäre es natürlich super, aber davon gehe ich mal nicht aus was? Dann stellt sich noch die Frage mit dem Passwort. Auch das liegt in Klartext vor - ich weiß aber nicht auf welche Art und Weise ich das verschlüsseln muss für Drupal, denn in Drupal stehen die Passwörter ja nicht in Klartext.

Das geht mit Hilfe von Migrate, aber es erfordert ein eigenes Modul für den Import. Es gibt da ein Kochbuch-Beispiel für den Import von User-Daten in Profile2, bei dem erst die User angelegt werden und dann die Profile-Daten im zweiten Schritt importiert und an den User angebunden werden. In Schritt 1 wird auch das Passwort im Klartext importiert. Das habe ich bereits getestet und das klappt.

Beste Grüße
Werner

Also ich habe jetzt mal alle Felder angelegt, welche ich brauchen werde und dann manuell testweise Benutzer angelegt in PHPmyadmin und das hat geklappt, wenn man versteht was wo rein kommt. Also werde ich jetzt mal versuchen ein PHP Script für den Import zu schreiben ^^ Alle Daten sind gesichert, es kann also nicht so viel passieren.

Ich würde nicht direkt in die DB schreiben, sondern das ganze dann über ein Modul lösen.

Dieses Modul lädt die Daten aus deiner Nutzertabelle und fügt die User dann über eine Schleife in ein Account-Objekt und dieses über die Funktion user_save() ein:

Ich verstehe nicht so richtig was dagegen spricht es nicht als Modul zu machen ^^ ? Ich habe einfach noch zu wenig Erfahrung um so ein Modul zu schreiben. Ich meine ich weiß einfach mal gar nichts darüber. Ich meine da muss es ja auch irgendwelche Benutzeroberflächen und so im Bakcend geben - das wäre ja total oversized. Ein normales PHP Script und ein Cronejob tun es doch auch.

Ich meine die Daten sind 100% Sicher so aufbereitet wie man es braucht, weil Sie in dem Verband auf Sharepoint gepflegt werden. Also muss man sic hdarüber schonmal keine Gedanken machen. Was also macht ein Modul notwendig?

Sieh Dir das Beispiel an. Das Backend dazu ist bereits im [do:migrate Migrate Modul] enthalten. Du bekommst Daten über direktes Eingeben in die Datenbank vermutlich nicht Drupal-konform eingepflegt. Zumindest hast Du ein hohes Risiko, daß irgendeine Verbindung fehlt.

Beste Grüße
Werner

mit dem feeds modul kannst du doch nodes oder user importieren oder andere dinge. also schau dir das ruhig einmal an

Habe ich gemacht. Leider ist es vom Funktionsumfang im Mapping zu eingeschränkt.

Konkret geht es um 3 Anforderungen, welche so nicht erfüllbar sind:

1. Ich kann die ganzen zusätzlichen Felder die ich für die Nutzerprofile angelegt habe nicht mappen (In der Auswahl sind nur grundlegende Daten zuzuordnen, wie Passwort, Username, EMail)
2. Ich muss eigentlich die User Role aus einem Kürzel in den Daten generieren (Ggf. könnte ich das Kürzel noch in die ID umwandeln, die der User Role in Drupal entspricht, so dass sie die richtige Form haben, aber User Role ist nicht in der Auswahl beim Mapping)
3. Da die Daten (dummerweise, aber ich kann es leider nicht ändern) offlien in Sharepoint von dem Verband gepflegt werden, aber durchaus eine Passwortänderung des Users in Drupal möglich wäre, müsste man eigentlich einstellen können, dass wenn ein User vorhanden ist, von diesem alle Daten nochmal überschrieben werden (alles könnte sich ja ändern) bis auf das Passwort

Punkt 3. Könnte man ja unter Umständen schonmal umgehen, wenn man irgendwie die Möglichkeit ausstellen kann das User ihr Passwort ändern.

Also erstmal zum Tutorial, dann zum Einwand :)

Das Tutorial ist ganz gut, ABER: Es arbeitet mit Profile 2. Profile 2 bringt wieder viel zu viele Funktionen mit. Außerdem bietet es standartmäßig eben durch seine Trennung von Useraccount und Anzeigeprofil keine hidden-fields. Aber vielleicht 50% der Userdaten sollen dem User gar nicht zur Verfügung stehen, sondern ich muss sie später nur nutzen um verschieden Ausgaben zu generieren. Das wird zu kompliziert.

Zum Einwand. Also wenn ich die komplette Struktur des Profils in Drupal im Backend anlege (Profil, Zusatzfelder und User Roles) und dann einen Datensatz anlege, dann weiß ich ja welche Form die Daten haben müssen. Das habe ich mir auch angeschaut. Eigentlich sehe ich das wenig Fehlerpotential. Aber ich verstehe den Einwand auch. Nur habe ich bis jetzt einfach keine gangbare Lösung gefunden das ganze mit Boardmitteln umzusetzen. Dieses Migration Modul entzieht sich noch etwas meinem Verständnis ehrlich gesagt - ein großer Nachteil Drupal : 90% der Informationsquellen sind in Englisch. Englisches lesen, gerade bei Themen von denen ich noch keine Ahnung habe ist für mich sehr sehr anstrengend :D

Also im Prinzip um es kurz zu fassen bräuchte ich nur eine Möglichkeit neue Targets zu erfassen für das Mapping im Feeds Modul und ich müsste es ausstellen können, das via Drupal die Passwörter verändert werden ^^ Das kann der Verband dann intern klären - wäre aber nicht so schlimm ich will euch gar nicht verraten wie dumm die aktuellen passwörter entstehen :D !

Wäre das denn nicht irgendwie über folgende Datei möglich:
http://drupalcontrib.org/api/drupal/contributions!feeds!plugins!FeedsUserProcessor.inc/function/FeedsUserProcessor%3A%3AgetMappingTargets/7

??

Wenn ich im Profil ein Zusatzfeld anlege, werden dabei 2 Tabellen angelegt. Erstelle ich zum Beispiel das Feld "website" dann enstehen dadurch die Tabellen field_data_field_website und field_revision_field_website.
Ich weiß nicht ob man das beim Einfügrne zusätlicher Mapping Targets irgendwie beachten müsste.

EDIT: Das UserRole Problem ist gelöst. Mit noch mehr recherche habe ich einen Patche gefunden. Der hat zwar als Patch erstmal nicht funktioniert, weil sämtliche Zeilenangaben falsch waren etc, aber ich habe die Stellen zum Einfügen dann einfach manuell rausgesucht und den zusätzlichen Code eingefügt.

Unter:

Habe ich folgendes eingefügt:

Und unter:

Habe ich folgendes eingefügt:

Ich habe jetzt einen Ansatz um Benutzerdefinierte Felder hinzuzufügen.

Im Post zuvor sieht man ja, das für jedes Feld, das man zusätzlich als Target deklarieren möchte zwei bereiche deklariert werden muss (Beispiel User Role). Einmal der Bereich, der die Eingabe verarbeitet:

und einmal der Bereich der für die Bezeichnung und Beschreibung des neuen Targets zuständig ist. Außerdem habe ich eben herausgefunden, das wohl zusätzliche Profilfelder auch in der $account Variable ansprechbar sind:

So der Account ist ja in der modules/feeds/plugins/FeedsUserProcessor.inc.php wohl schon geladen. Mit fehlen jetzt im Prinzip nur noch zwei Informationen. 1. wie finde ich die Bezeichnung heraus, welche hier mit 'field_some_custom_field' ausgeschrieben ist? Wie zeichen ich es so aus, dass es dieses Script am Ende auch speichert :D ?

Stelle es mir am Ende Irgendwie so vor:

und

Ich hatte nie gesagt, daß Du Profile2 verwenden solltest. Wenn Dir der erste Schritt reicht, ist das Beispiel für dich trotzdem passend. Du kannst dann den zweiten Abschnitt weglassen. Felder im "normalen" User-Profil werden ja in Schritt 1 gesetzt. Da kannst Du Dir die Vorgehensweise ansehen.
Du wirst Dich daran gewöhnen müssen, daß die Dokumentation, besonders bei sehr speziellen Modulen, nur auf Englisch zu haben ist. Das ist bei Open Source nun mal so.

Beste Grüße
Werner

Ja ich glaube trotzdem, dass der Weg den ich mit meinen Recherchen eingeschlagen habe ein komfortabler ist. Und ich glaube er ist auch umsetzbar, und zwar mit wesentlich weniger Aufwand als mit dem Migration tool :) Werde dir nochmal bescheid geben, sobald ich weiß, ich ich das abspeicher :)

Ja das mit den englischen Diskussionen und Dokumentationen ist ganz klar. Aber anstrengend bleibt es trotzdem ^^ zumal ich dann auch mit dictionary nicht alle zusammenhänge verstehe. Ich hätte bevor ich Drupal angepackt habe nicht gedacht, dass die deutsche Community doch relativ klein oder zumindest nicht allzu aktiv ist (zumindest im deutschsprachigen Bereich). Aber ich geb ja mein bestes :)