-
Notifications
You must be signed in to change notification settings - Fork 9
Integrere medlemsdatabasen #8
Comments
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. |
@matsasc Tenker du at man modellerer roller som en egen modell? Og at hvis man er f.eks. barfunk er man implisitt i "bargruppa"? |
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). |
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? |
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. |
medlemssystemet burde definitivt være uavhengig av intern/tilgangssystem ja |
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. |
Man har integrert medlemssystemet i #32 |
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
:core.User
core.Semester
core.User
i betydning av hvem som registrerte oppføringenOpprette medlem uten brukernavn?
Rettigheter for endring av data
Sletting av medlemmer
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.
The text was updated successfully, but these errors were encountered: