Skip to content
This repository has been archived by the owner on Nov 14, 2024. It is now read-only.

Integrere medlemsdatabasen #8

Closed
henrist opened this issue Feb 27, 2015 · 8 comments
Closed

Integrere medlemsdatabasen #8

henrist opened this issue Feb 27, 2015 · 8 comments

Comments

@henrist
Copy link
Member

henrist commented Feb 27, 2015

Medlemsdatabasen (se https://github.com/vegarang/medlemssystem_django/) kjører på en laptop som ligger på økonomikontoret. Å få denne på nett kan gi nye muligheter knyttet mot medlemslistene.

Planen er å integere medlemssystemet inn i dette internsystemet. Det betyr i praksis at meste parten skrives på nytt, med inspirasjon fra det gamle systemet.

I en tidlig versjon av denne issuen var det omtalt internstatus, bonger, kort-tilganger m.v. Dette er imidlertid nå holdt utenom issuen.

Modellering

Modell member:

  • referanse til core.User
  • referanse til core.Semester
  • type (enum: semester, lifetime, honored)
  • time
  • sell_value (f.eks. 30 for semstermedlem og 270/300 for livstidsmedlemsskap)
  • sell_type (enum: pub, kafé, other)
  • referanse til core.User i betydning av hvem som registrerte oppføringen
  • comment

Opprette medlem uten brukernavn?

  • Må avklares. Skal dette være mulig, og hvordan skal vi håndtere det ift. core.User-objektet? Det må vel ha brukernavn?

Rettigheter for endring av data

  • Må avklares. Kan foreløpig begrense dette til admins og utvide senere.

Sletting av medlemmer

  • Må avklares. Hvordan skal dette håndteres? I hvilke tilfeller kan medlemmer slettes (kun ved feilreg?)?

Generering av livstidsmedlemskort

Generering av livstidsmedlemskort for nye registreringer. Se i sammenheng med tilsvarende problemstilling for internkort: #14

Migrering av data

Det må avklares hvordan data fra det gamle systemet skal flyttes over, og om det i det hele tatt skal flyttes over. Utfordringen ligger i stor grad i at det gamle systemet ikke har brukernavn på oppføringene og at forskjellige navn kan være knyttet mot den samme personen.

Annet

Se også #14 for internstatus/internkort.

@matsasc
Copy link
Contributor

matsasc commented Feb 27, 2015

one to many eller many to many kan være mer naturlig for grupper og roller. veldig mange har veldig mange forskjellige roller og grupper.

EDIT: Egentlig trenger man ikke grupper i internobjektene da dette kan fint ligge i rollen. Da alle roller har grupper og det er umulig å bli intern uten å ha minimum en rolle.

@henrist
Copy link
Member Author

henrist commented Feb 28, 2015

@matsasc Tenker du at man modellerer roller som en egen modell? Og at hvis man er f.eks. barfunk er man implisitt i "bargruppa"?

@matsasc
Copy link
Contributor

matsasc commented Feb 28, 2015

Ja, og er man f.eks kasserer så er man implisitt i økonomigruppa og hovedstyret.

Selv om det så tror jeg man kanskje også fint kan ha en egen liten gruppe modell, som også har oversikt over hvilke roller som er i gruppen, hvem som leder den(evt hvilken rolle som leder den).

Om legger man også inn informasjon om hvem som er leder i disse gruppene kan man lage noe logikk rundt det når man skal legge inn medlemmer i gruppene(gjennom rollene). så bare gruppelederen og f.eks internans kan legge folk i en gruppe.

Det kan man igjen bruke for tilgangshåndtering, generere opp internkort med CV på baksiden som visse personer har mast om siden før jeg ble internansvarlig. Og sikkert noen andre morsomme saker(f.eks når internansvarlig skal fordele sosialmidler til grupper så slipper han å sende en epost ut til gruppeledere om størelsen på gruppene, fordi i en perfekt verden så legger gruppelederene den personen inn i gruppen).

@ljodal
Copy link
Contributor

ljodal commented May 31, 2015

Nå som påloggingsløsningen er klar kan vi kanskje begynne på dette? Er planen å integrere tilgangskontroll med medlemssytemet eller skal vi opprette et separat issue for det?

@henrist
Copy link
Member Author

henrist commented May 31, 2015

Jeg er litt usikker på hvordan acl-stuff i Django fungerer. Vil tro det enkleste er å holde tilganger og medlemsskap litt separert, og heller bygge på/utvide senere.

Inntil videre settes man som admin manuelt gjennom Django-admin.

En fordel er derimot om man bruker acl for diverse rettigheter i medlemssystemet, slik at det er klart fra start. Vi bør kanskje kartlegge litt hvilke rettigheter som skal påkreves i medlemssystemet.

image

@matsasc
Copy link
Contributor

matsasc commented Jun 1, 2015

medlemssystemet burde definitivt være uavhengig av intern/tilgangssystem ja

@henrist
Copy link
Member Author

henrist commented Jun 3, 2015

Har oppdatert en del info i issuen her nå. Fjernet internstatus og stæsj som er flyttet til #14. Har lagt inn noen flere punkter som må avklares, gi gjerne kommentar på de.

@matsasc
Copy link
Contributor

matsasc commented Mar 12, 2016

Man har integrert medlemssystemet i #32

@matsasc matsasc closed this as completed Mar 12, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants