[PPNL-Techteam] drupal ldap versie

[Casper Gielen]

On 05/15/2012 11:11 AM, Bèr Kessels wrote:
> Hallo,
> 
> Eerst even voorstellen. Ik ben Bèr Kessels, zelfstandig Open Source
> ontwikkelaar en verdien ongeveer 11 jaar mijn brood met Drupal.
> Inmiddels overigens niet meer exclusief, maar dat is een ander verhaal.
> Ik heb alles gedaan: core ontwikkeling, module-ontwikkeling,
> documentatie, trainingen, consultancy (bah!) en vooral veel vloeken en
> tieren. Ik ben bijna overal terug te vinden als "berkes" al dan niet met
> een apending ervoor.
> 
> Ik bood me aan op IRC om wat hulp bij Drupal te geven. Bij dezen.


Hoi Bèr,
welkom bij de club!

>>
>> Ja, op het moment dat je inlogt kijkt Drupal in LDAP. Als de gevraagde gebruiker daar in bestaat
>> maakt Drupal zelf een account toe. Dat is inderdaad eenvoudig achteraf toe te voegen.
> 
> Eenvoudig toe te voegen, Niet eenvoudig weer weg te halen. dus niet iets
> dat je "even een paar maanden probeert", maar zeer geschikt om in een
> later stadium te implementeren.
> Je moet dan alleen wél besluiten wat je doet met de al aangemaakte
> users. Als dat er duizenden zijn is een automatische migratie handig,
> anders gooi je de oude accounts weg en ga je daarna met de LDAP-enabled
> accounts werken. "Anna" zonder LDAP is namelijk niet persé hetzelfde
> account als "Anna.ldap.ppnl.org".

De keuze om LDAP te gebruiken is al gemaakt (en is al in productie).
Deze discussie ging alleen over de development-versie van de site.
Daarop hoeven alleen developers in te kunnen loggen en die kunnen
voorlopig ook met drupal-only accounts toe. Bob heeft een nieuwe devel.
omgeving opgezet op een andere server. Die heeft geen toegang tot de
ldap-server en eingelijk lijkt mij dat maar beter ook. Wwe zouden
evtentueel ook een ldap voor dev. doeleinden kunnen opzetten, maar ik
heb liever geen echte persoonsgegevens in onze dev. omgeving.

De productie-versie haalt alle gebruikers uit LDAP (met uitzondering van
1 admin account voor noodgevallen).

> Mijn ervaringen hiermee zijn ronduit slecht. CiviCRM werkt aardig, maar
> komt absoluut niet in de buurt bij wat "de industrie" verwacht van CRM
> (dit enkel ter informatie, want de PPNL is uiteraard niet "de
> industrie"). Hier is vooral van belang dat de koppeling erg
> houtje-touwtje is. Zoals ook te verwachten is als je twee losstaande
> applicaties in elkaars Database en resources gaat laten rondpoeren.

He, ervaring, altijd fijn :)
De keuze voor CiviCRM is niet bijzonder lang of hard doordacht. Na een
middagje vergelijken en experimenteren leek Civi het beste aan te
sluiten bij wat wij willen en hebben. Als het echt een onverstandige
keuze is kunnen we er nu nog makkelijk van af.

> Als je geen koppeling nodig hebt, is mijn zeer uitdrukkelijk advies om
> die twee dan ook niet te koppelen.
> Temeer omdat je er moeilijk vanaf komt. Besluit je over een half jaar
> toch maar met SugarCRM, FatfreeCRM of OpenERP verder te gaan, dan is
> zeer waarschijnlijk het losmaken van CiviCRM van Drupal het meeste werk.
> Pas als duidelijk is dat CiviCRM een blijvertje is, én informatie
> uitgewisseld moet worden tussen CMS en CRM, is mijn advies het ook te
> koppelen.

Dank voor deze woorden, ze bevestigen de gevoelens die ik al had.
Op dit moment zie ik twee taken voor CiviCRM.
1. beheer externe relaties (een adresboek voor nieuwsredacties,
politieke partijen, woordvoerders en anderen die wij soms gericht willen
kunnen mailen)

2. ledenbeheer (registreren van leden en bijhouden van contributie)

Voor taak 1 is een koppeling met de hoofdsite helemaal niet nodig. Dit
deel kunnen we als zelfstandige applicatie draaien zonder verdere
afhankelijkheden of koppelingen.

Voor taak 2 zou een koppeling wel handig zijn, zodat als iemand lid
wordt hij ook automatisch een inlog-account krijgt voor de verschillende
diensten. Voor dat deel zou een koppeling handig zijn.
In plaats van een gedeelde mysql-database zouden we ook een koppeling
via LDAP kunnen overwegen.
Er is een manier om de civicrm info via LDAP te exporteren. Dat is een
interface waar ik meer vertrouwen in heb maar ook hier moeten we
afweging maken tussen lusten en lasten.

-- 
Casper

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.piratenpartij.nl/mailman/private/techteam/attachments/20120515/d5b9c9d5/attachment.pgp>