Medlemsdatabase/arbeidsmøte 2015-04-26

Fra Piratpartiets Wiki
Revisjon per 3. des. 2021 kl. 09:03 av Tobixen (diskusjon | bidrag) (Vurderinger av verktøyene: - rettskriving)
(diff) ← Eldre revisjon | Nåværende revisjon (diff) | Nyere revisjon → (diff)
Hopp til: navigasjon, søk

Se også Medlemsdatabase

Innkalling

Tobias kalte inn til møte, med mandat fra forrige sentralstyremøte. Innkallingen gikk ut pr mail til tech og sek. Gorm har fått mandat til å lete etter andre folk som kan bidra til arbeidet. På design, bearbeiding og ferdigstilling av strata/ data. Men men denne personen fikk ikke anledning til å møte pga. kort tidsfrist (under en uke).

Møtested ble satt til Sukkerbiten utenfor Operaen i Oslo for de som har mulighet til å møte opp der, samt #pirtech.no og https://pad.piratpartiet.no/p/Medlemsdatabase for de som ikke hadde mulighet. Dette ble ikke presisert før rett i forkant av møtet, Tobias tar selvkritikk for dette. Pga forvirring om oppmøtested og tid ble møtet noe utsatt. Kenneth Polden ønsket VoIP, og vi kastet opp en Skypeforbindelse. Neste møte bør vi ha Mumble klart.

Formål med møtet

Gå igjennom og gjøre research på ulike alternativer til ny medlemsdatabase. Utarbeide en konkret anbefaling som sentralstyret kan ta stilling til. Eventuelt, sette opp prototype.

Oppmøte

  • Middelthun (fysisk tilstedet)
  • Tobias Brox (fysisk tilstedet)
  • Kenneth Polden (IRC, skype og pad - bidro ikke til tekniske vurderinger)
  • Krister Borge (IRC, skype og pad)

I tillegg bidro Gorm Hanssen, Øyvind Nondal og andre til pad'en.

Gjennomgang av kravspek

Forhold til lovgivning var ikke klarlagt i utkastet til kravspek. Kenneth Polden, med bistand fra Krister Borge studerte Lovdata ila møtet. Det dukket også opp et par andre editeringsforslag, dette blir innarbeidet i kravspek'en på wiki'en.

Grunnleggende design

Det er enighet (Middelthun/Brox/Borge/Gorm) om at vi bør ha et modulbasert system, hvor modulene snakker med en sentral database - enten gjennom direkte databasekontakt eller gjennom lag med "lim". Hver modul skal ha dedikerte funksjoner ifht kravspesifikasjonen. Programvare som ikke er en direkte del av medlemsdatabasesystemet, men som trenger tilgang til medlemsregisteret (brukerdatabasen) kaller vi "verktøy". Eksempler på verktøy: mediawiki, reddit, zimbra.

Moduler som utgjør en sentral del av medlemsdatabasen bør ha direkte tilgang til databasen. Verktøy som utvikles internt kan også få direkte tilgang til databasen dersom det ansees som enklest eller nødvendig.

De to mest utbredte standardene for "lim" er LDAP og OpenID. Det meste av verktøy der ute støtter minst én av disse standardene. Vi bør støtte begge, for å få størst mulig frihet til å installere ulike typer verktøy.

Ved å lage systemet modulbasert, oppnår vi disse fordelene:

  • Raskere implementering av den funksjonaliteten som er viktigst for oss
  • Et åpent system som lettvint kan vidreutvikles til fremtidige behov
  • Vi blir ikke "innelåst" i en produktpakke

Dagens løsning

Dagens løsning er et helt enkelt php-script som Middelthun brukte fire kveldstimer på å sette sammen. Det vedlikeholder en enkel tabell i en postgresdatabase. Dataene kan enkelt bearbeides eller eksporteres.

Oppramsing av mulige systemer/komponenter vi kan benytte

Vurderinger av verktøyene

  • LDAP (Lightweight Directory Access Protocol) - gammel traver. Det bør være mulig å greie seg uten LDAP, men da det er mange verktøy som støtter LDAP men ikke OpenID, vurderer vi det dithen at LDAP er viktig. LDAP er først og fremst en standard, men "standardimplementasjonen" er en fullverdig brukerdatabase. Kanskje zimbraimplementasjonen kan brukes.
  • OpenID - dette er den moderne standarden for Single-Sign-On. Tobias tar ansvar for videre research på standarden og mulige implementasjoner.
  • Wordpress-moduler for medlemsdatabaser og butikkløsninger: Vi (Middelthun, Brox og Borge) har en mistanke om at det er et relativt stort sprik mellom den funksjonaliten vi faktisk trenger og den funksjonaliteten disse modulene vil gi oss, samt en tro på at den biten hvor ønsket funksjonalitet overlapper faktisk funksjonalitet er relativt trivielt å få implementert fra scratch. Vi er skeptiske til sikkerheten til WordPress, og vurderer det dithen at det innebærer en sikkerhetsrisiko å la administrasjon av brukerdatabasen gå igjennom Wordpress. Vi har derfor valgt å ikke gå nærmere inn på disse modulene i denne omgangen.
  • OpenCart - her har vi faktisk en betalingsløsning på vei opp allerede. Det bør være mulig å få rutet innbetaling av medlemskontingent og donasjoner også gjennom denne modulen. Modulen tilbyr også registreringsfunksjonalitet for enkle personopplysninger, vi bør se nærmere på om vi skal la brukerene få registrere konti og personopplysninger gjennom OpenCart, eller om vi heller bør få OpenCart til å lese dette fra medlemsdatabasen. Vi håper at Bjerkeli kan gi utfyllende kommentarer.
  • Dagens PHP-script. Utvikleren er ikke fornøyd med systemet og ønsker det lagt dødt, men den fungerer inntil vi har noe annet på plass.
  • https://wordpress.org/plugins/openid/ - openid-løsning til WP. Noen (TODO: konkretiser "noen") burde se på denne.
  • Svenskenes system - Middelthun finner frem informasjon om det.
  • Zimbra - tobias ser på hvordan zimbra virker mtp OpenID og LDAP, samt hvordan vi kan gå frem for å få Zimbra integrert med en brukerdatabase.

Gorm innvender at vi bør bruke litt tid på gjøre oss rimelig ferdige med en god kravspek før vi begynner å vurdere tekniske løsninger. Han innvender også at vi ikke bør ha for mange teknologier å forholde oss til, av bla.a driftshensyn. Nå er WP allerede i bruk, og er videre enig i bl.a. Middelthun sitt perspektiv av modulbasert løsning.

Avrunding

Dette var alt vi fikk tid til nå.

Tobias tar ansvar for å lage et møtereferat (dette dokumentet), samt arbeide videre med noe som kan presenteres for sentralstyret, bl.a. noen graphviz-figurer.