Robokop kravspesifikasjon

Mål for endringer fra versjon 2.5 til versjon 3.0. Hovedmålet er å støtte opp under planlegging og fordeling av rom, ikke bare være en autoritativ kilde. Med andre ord: La det være mulig å legge inn forespørsler for gjenger, som så skal kunne godkjennes eller endres av administrator. (Per i dag gjøres dette i et Google-doc.)

Funksjonelle krav

Alle Husfolk skal kunne legge inn forespørsler om reservasjoner, men administrator (KK) må godkjenne.
Vi trenger et brukergrensesnitt for å la administratoren behandle forespørsler. Dette verktøyet skal tilby all informasjon admin trenger for å gjøre riktige valg, nemlig informasjon om arrangementet (navn, type, gjeng, etc.), ressurser man trenger (rom), reservasjoner i konflikt
Man må håndtere at en repeterende hendelse kan være i konflikt med et annet arrangement (f.eks.: Symforch har Storsalen hver onsdag, men det kan være aktuelt å flytte øvingen for å få plass til en konsert).
Hente personer fra MDB2 (eller AD) for å unngå et eget personregister i RoBoKop.

Implementasjonsdetaljer

Det kan være lov med overlappende arrangementer i unntakstilfeller, men det må være markert tydelig i UIet.
Systemet skal validere brukerinput grundig og gi hjelpsomme feilmeldinger.
Legge til støtte for flere typer ressurser, f.eks. projektorer, biler, etc., og ha et tydelig skille mellom dem i UI.
En vanlig bruker skal ikke kunne endre på en godkjent reservasjon. Optional: Man skal kunne be om en endring på en godkjent reservasjon. (I første versjon kan dette tas manuelt ved å sende epost.)
Optional: Send epost til administrator om at en forespørsel er lagt inn, og send epost til brukere når forespørsel er behandlet.
Optional: Forbedre dato-felt med en kalender.

Databaseendringer

Se på om dagens system med lagrede ukenummer fortsatt er hensiktsmessig.
Databasen per i dag mangler foreign keys og grunnleggende constraints. Det burde fikses.

Use-cases

KLST skal arrangere en konsert. De går inn på RoBoKop, ser på kalenderen og finner en dag Storsalen er ledig, og legger inn en forespørsel. Neste dag får bookeren en epost om at forespørselen er godkjent av administratoren.
Orkesteret vil ha øving i Storsalen førstkommende søndag. De ser i kalenderen og ser at KLST allerede har reservert rommet. De mener at de har størst rett på rommet, og legger inn en forespørsel likevel. Personen får en tydelig advarsel om at rommet allerede er reservert i det tidsrommet, men fortsetter likevel. Neste dag får personen en epost om at forespørselen ble avvist fordi administrator mente at KLST hadde prioritet.
Bettan kommer på jobb, og ser at det er fem romforespørsler. Hun går til romforespørselsoversikten, ser at de tre første ikke har noen konflikter og godkjenner dem. De to siste er i konflikt, så hun får se informasjonen hun trenger for å bedømme hvilken som skal bli godkjent. Hun velger å godkjenne den første og avslå den andre. Hun skriver en begrunnelse for avslaget. Deretter får de respektive bookerne epost om dette.
En funksjonær sitter under programperioden og planlegger quiz i Edgar hver onsdag kveld kl. 18. Han går i RoBoKop og legger inn en repeterende forespørsel (hver onsdag fra 1. april til 28. april, kl. 17.00–19.00). En av kveldene har Strindens forespurt konsert kl. 18, så funken får en varsel om at denne forespørselen er i konflikt. Han får spørsmål om å flytte den, og velger å ikke søke den dagen, men heller lage en separat event kl. 20. Dagen etter får han epost som bekrefter at forespørslene ble godkjent.

Mål til senere

Mobilvennlighet.
Gi dørtilgang til reserverte rom.
Tillate flere typer repeterende forespørsler/reservasjoner (dag, uke, måned).
Se på i hvilken grad vi kan gjøre forsidevisningen for brukere mer informativ.

Åpne spørsmål

Er bar, tappekran og vann felter som brukes?
Brukes vaskelisten?

Lenker: Start, robokop