Relocate wiki from trac
This commit is contained in:
parent
6dfee80fff
commit
429a38fa57
|
@ -0,0 +1,12 @@
|
|||
# Medlemsdatabase NG
|
||||
|
||||
Medlemsdatabase NG (mdb-ng) er en ny medlemsdatabase for PVV, skrevet fra scratch i python.
|
||||
|
||||
mdb-ng bruker en liste over keyword/value-par for å lagre informasjon om hver bruker. All informasjon ligger i RCS, så endringer av informasjon om en bruker vil ikke ødelegge historikken.
|
||||
|
||||
## Startpunkter for videre lesing
|
||||
|
||||
- [Liste over features, implementerte og ønskede](./wiki/FeatureList.md)
|
||||
- [Frequently Asked Questions (FAQ)](./wiki/FrequentlyAskedQuestions.md)
|
||||
- [Designdokument](./wiki/DesignDokument.md)
|
||||
- [Databasestruktur](./wiki/DataBaseStructure.md)
|
|
@ -0,0 +1,47 @@
|
|||
# Databasestruktur
|
||||
|
||||
Her er et forslag til databasestruktur i Mdb-NG. For en gitt databasestruktur, sjekk om den kan oppfylle kravene i FeatureList.
|
||||
|
||||
## Tabeller
|
||||
|
||||
### Personer
|
||||
|
||||
- ID
|
||||
- Fullt navn
|
||||
- MTime
|
||||
- Comment
|
||||
|
||||
`ID` er en unik id for en person, uavhengig av hvor mange brukernavn og UIDer personen har hatt. Det tillater også at en person har flere brukernavn. Jeg tror det er et par eksempler på det i PVV for tiden. `MTime` sier når raden ble opprettet. Når et av feltene endres lages det en ny rad for personen hvor de uendrede feltene kopieres fra forrige rad.
|
||||
|
||||
### Unix-detaljer
|
||||
|
||||
- Personer:ID
|
||||
- ID
|
||||
- UID
|
||||
- Brukernavn
|
||||
- Hjemmekatalog
|
||||
- Primær gruppe
|
||||
- CTime
|
||||
- MTime
|
||||
- Comment
|
||||
|
||||
### Gruppetilhørighet
|
||||
|
||||
- ID
|
||||
- UID
|
||||
- GID
|
||||
- CTime
|
||||
- MTime
|
||||
- Comment
|
||||
|
||||
### Fysisk tilgang
|
||||
|
||||
- ID
|
||||
- Personer:ID
|
||||
- Verkstednøkkel
|
||||
- Maskinromnøkkel
|
||||
- Kortnummer
|
||||
- Korttilgang utløper
|
||||
- CTime
|
||||
- MTime
|
||||
- Comment
|
|
@ -0,0 +1,19 @@
|
|||
|
||||
## Dataformat
|
||||
|
||||
Databasen er implementert som en katalog med tekstfiler. Hver fil inneholder informasjon om ett medlem og er underlagt revisjonskontroll med RCS. Filene har et key: value-format, hvor blanke tegn på slutten og begynnelsen av både nøkkel og verdi blir strippet bort. Hvilke felter som er gyldige og om de kan ha flere verdier fins i `.format` i databasekatalogen.
|
||||
|
||||
I format-filen kan hvert felt kan være spesifisert enten som scalar eller som list. Dette avgjør om et felt kan opptre en eller flere ganger i samme fil. Hvert element i en liste må komme som en egen linje. Dette gjør at historikken i RCS holder styr på de enkelte elementene i lista.
|
||||
|
||||
Midlertidig sett med felter er:
|
||||
|
||||
```
|
||||
username: scalar
|
||||
realname: scalar
|
||||
uid: scalar
|
||||
disk: list # hvert element i lista er en 2-tuple adskilt med space
|
||||
bdb-uid: scalar
|
||||
bdb-username: scalar
|
||||
purged: scalar
|
||||
membership: list # hvert element i lista er en 2-tuple adskilt med space
|
||||
```
|
|
@ -0,0 +1,31 @@
|
|||
# Problemene som skal løses
|
||||
|
||||
- Hvem er medlemmer i PVV?
|
||||
- Når løper medlemskapet til et medlem ut?
|
||||
- Hvem har korttilgang til PVV?
|
||||
- Når går korttilgangen til et medlem ut?
|
||||
- Hvem har nøkler til verkstedet?
|
||||
- Hvem har nøkler til serverrommet?
|
||||
|
||||
# Informasjon om brukere
|
||||
|
||||
- Brukernavn
|
||||
- Fullt navn
|
||||
- Medlemsperiode
|
||||
- Når medlemsperioden er betalt
|
||||
- Hvor langt fremover adgangskortet er aktivert
|
||||
|
||||
# Uavklarte spørsmål
|
||||
|
||||
## Endring av brukernavn
|
||||
|
||||
Det hender at brukere endrer brukernavn, typisk i pvv etter at de har fått brukernavnet endret hos stud. Skal dette kunne trackes på noen måte?
|
||||
|
||||
## Endring av UID
|
||||
|
||||
Samme som med brukernavn. Dette er sannsynligvis ikke et stort problem lenger, siden hjemmekataloger ikke monteres til stud lenger.
|
||||
|
||||
## Hvilke endringer skal logges?
|
||||
|
||||
Holder det å ha cdate og mdate på bruker-records, eller skal alle endringer logges?
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# Frequently Asked Questions
|
||||
|
||||
## Generelt
|
||||
|
||||
### Navnevalg
|
||||
|
||||
#### Hvorfor heter det Medlemsdatabase NG? Har vi hatt en medlemsdatabase før?
|
||||
|
||||
Ja, vi har hatt en medlemsdatabase før. Faktisk har vi også hatt et prosjekt før som het Medlemsdatabase NG, men som det aldri ble noe av. Vi valgte dog NG til denne databasen uten å vite at det allerede hadde vært et forsøk på å lage en med samme navn. Ingen av oss som nå lager mdb-ng var i PVV forrige gang dette navnet ble brukt.
|
||||
|
||||
### Problemdomene
|
||||
|
||||
#### Hvilke problemer har vi som krever en medlemsdatabase?
|
||||
|
||||
De to viktigste bruksområdene for mdb-ng er
|
||||
|
||||
- å holde styr på hvem som har betalt medlemskontingent, og
|
||||
- å vite hvor mye disk folk har kjøpt og hvilke diskpartisjoner en gitt bruker eier.
|
||||
|
||||
Når og hvor mye en person betaler i kontingent er ikke helt trivielt i PVV. Dette skyldes flere faktorer. Blant annet har vi byttet regnskapssystem for noen år siden, men det var flere som betalte for flere år fram i tid før regnskapssystemet ble byttet ut. Disse transaksjonene ligger ikke i det nye regnskapssystemet. I tillegg glemmer folk ofte av å betale kontingent, siden ingen minner dem på det. Når de da betaler kontingent får man plutselig inn betalinger for perioder som allerede har gått, samt for ganske langt inn i fremtiden.
|
Reference in New Issue