DRAFT Mottagningswebben Kravspecifikation

Transkript

1 DRAFT Mottagningswebben Kravspecifikation Patrik Stenmark Contents 1 Introduktion 2 2 Ordlista 2 3 Användarnas mål Titel Daddor Drifvare Doqumenterister Kassören Utomstående Översikt över de viktigaste funktionerna Anmälningar Användarhantering Biljetthantering Ansvarsområden & testamenten Utlånade prylar Detaljbeskrivning av funktioner Anmälningar Användarhantering Biljetthantering CRUD-funktioner för arrangemang n0llans köp Externa beställningar Exportmöjligheter Ansvarsområden & testamenten CRUD-funktionalitet för ansvarsområden Visa ansvarsområden Uppläggning av testamenten Översikt över inlämnade testamenten Överföring mellan år Utlånade prylar

2 6 Milestones Anmälningar PlOqsvik Offentliggörandet Jourveckan Testamenteinlämning Introduktion Datasektionens mottagning har under en lång tid använt sig av en mängd olika filer för att hålla koll på all den information som krävs för att hålla koll på mottagningens stora organisation. Dessa filer ligger utspridda på mottagningskontot och är i olika format, olika teckenkodning och har generellt sätt ingen standardutformning. Målet med mottagningswebben är att förenkla denna informationshantering och på så sätt göra det enklare för alla inblandade att hålla koll på allt. 2 Ordlista För att undvika förvirring är här en ordlista med de ord som används i dokumentet. Funktionär En mottagningsaktiv person. Detta inkluderar titel, daddor, doqumenterister och drifvare Ansvarsområde Ett ansvarsområde i stil med bärbarstillfälledadda, LQ-sittning, byggdadda Testamente En sammanfattning av arbetet med ett ansvarsområde. Detta görs efter mottagningens slut av alla funktionärer för varje ansvarsområde funktionären har haft, för att hjälpa nästa års funktionärer att veta vad man ska och inte ska göra. Mottagningskontot Den katalog i AFS där mottagningen har utrymme att lägga filer relaterade till mottagningen. n0llan Benämning på alla nyintagna, men också på en eller flera nyantagna. Mottagning En Mottagning i detta dokument innebär ett genomförande av en mottagning ett visst år. Externweb Den delen av som handlar om mottagningen. Internweb Den delen av STÖN som är för mottagningens användande. Några ord om ska och bör: Ordet ska innebär att detta är en högprioriterad funktion som verkligen behövs. Bör innebär att funktionen vore bra att ha men inte är lika högprioriterad. 3 Användarnas mål 3.1 Titel Ta emot anmälningar Hålla koll på utlånade prylar (Daddebyxor, etc). Få fram listor på ansvarsområden och ansvarig funktionär, grupperat antingen på ansvarsområde eller funktionärens namn Få fram information om testamenten, mer specifikt vilka som lämnat in vad. 2

3 Få ut info om ansvarsområde (Testamente, tidigare ansvariga, beskrivning). Se personuppgifter på funktionär Kunna ladda upp filer på webben så att alla kommer åt det lätt, istället för att lägga det på mottagningskontot. (Detta skulle kunna implementera som ett interface till mottagningskontot.) Drifvartitel ska kunna se vilka drifvare som lagt upp sina oreringar, och vilka som inte gjort. 3.2 Daddor Registrera biljettförsäljningar Registrera att man ringt n0llan Registrera n0llans allergier, avvikande kostvanor eller andra konstigheter med n0llan. Vid ett arr kunna få fram en lista på anmälda n0llan, med information om n0llan betalt, om n0llan ska ha med eller utan alkohol, allergier, specialkost. Allt en arrangerande dadda kan tänkas vilja veta. 3.3 Drifvare Lägga in sina oreringar i systemet, och se vilka ändringar som gjorts av vem. Nån form av formatering bör finnas så det kan göras snyggt. 3.4 Doqumenterister 3.5 Kassören Se vilka (Eller hur många?) biljetter som en viss n0llegrupp köpt till ett visst arr. 3.6 Utomstående Anmäla sig till fester och andra arrangemang. 4 Översikt över de viktigaste funktionerna De viktigaste funktionerna i systemet är hanteringen av anmälan, testamenten, biljetthanteringen och den allmänna hanteringen av personer (Både funktionärer och n0llan). 4.1 Anmälningar Den nuvarande hanteringen av anmälningar till mottagningen via mail är suboptimal. Att istället lägga anmälningar i databas vore, som Öfverdrif uttrycker det, smutt. 4.2 Användarhantering Nu finns alla personuppgifter för funktionärer tillgängliga för alla på mottagningskontot i en Excel-fil. Personuppgifter för n0llan finns nånstans hos titel, samt hos de enskilda daddorna. För att förenkla detta bör man lägga allt detta i mottagningswebben istället. När det gäller n0llan kan man även lägga in saker som allergier, specialkost och liknande där, för att sedan integrera detta med biljetthanteringssystemet. 3

4 4.3 Biljetthantering Förra mottagningens system med små lappar som man kryssade vilka som skulle gå var tämligen osmidigt. Detta borde man kunna sköta via ett elektroniskt formulär som funkar på samma sätt. Detta borde förenkla både för daddorna och kassören eftersom man slipper onödig pappershantering. Som en del av detta system så bör det också gå att få ut listor på anmälda till olika arrangemang. Dessa listor bör gå att få ut i olika format för utksrift och användning i andra program. Externa bokningar (Dvs bokningar som inte är n0llan) bör ha funktionalitet för att spara information som skrivs in baserat på personnummer. 4.4 Ansvarsområden & testamenten Även denna information finns nu på mottagningskontot. För titel har jobbet att sätta ihop papperna med information om ansvarsområden (testamenten, beskrivning, kontaktinformation) varit ett helt manuellt jobb. Detta borde automatiseras. Att lägga denna information på mottagningswebben gör också informationen mer lättillgänglig för daddan. Det är också enklare för daddor att lämna in sina testamenten om det bara handlar om att fylla i ett formulär istället för att lägga upp i en katalog på mottagningswebben. Genom detta slipper man också problem med olika format, olika encodings och andra liknande problem som uppstått. Detta skulle även förenkla för titel när de ska se vilka de måste följa efter med blåslampa för att de inte lämnat in sina testamenten. 4.5 Utlånade prylar Även detta är något som tidigare hanterades med papper och penna. Kan ersättas med laptop och STÖn. 5 Detaljbeskrivning av funktioner 5.1 Anmälningar Detta ska inte lagras i samma tabell som antagna funktionärer. Detta system kommer till viss del ligga på den externa hemsidan. Om tiden tillåter bör detta byggas på ett sätt som gör att anmälningsformuläret inte gör ändringar i STÖN-databasen. Då detta inte är samma tabell som resten av personinformationen är detta dock inte ett krav. Formuläret som intresserade teknologer fyller i ska ha fält för namn, epost samt vad de vill göra [TODO ska det vara gren eller mer i stil med intresseanmälan?]. Se bild anmalan-extern.png. Även om personen har körkort är intressant. Den interna sidan som visar anmälningar ska både kunna visa en lista sorterad på namn som visar vad personen vill göra (Se bild anmalan-intern-lista.png samt en lista grupperad efter vad den sökande vill göra (Se bild anmalan-intern-grupperad.png). Detta innebär att en person kan komma att finnas med på flera ställen om han sökt till flera grenar. Det ska finnas ett sätt att enkelt flytta över folk från anmälningsdatabasen till den riktiga databasen. Där ska det även på ett enkelt sätt gå att välja vilken mottagningsgren personen tillhör. När en användare loggar in första gången (alltså efter att ha blivit antagen och överflyttad) ska han tas till en sida där han är tvungen att fylla i all annan personinformation. 5.2 Användarhantering Funktionärer och n0llan ska hanteras som två olika saker. Detta för att det finns väldigt mycket information som bara är relevant för den ena eller den andra. Personuppgifter som ska lagras för båda typerna kan med fördel lagras i en separat tabell. 4

5 Systemet ska ha stöd för minst två nivåer av rättigheter, Titel och Icke-titel. Vissa saker, t ex skapa nya ansvarsområden kräver att man är titel. Systemet bör dock vara utbyggbart för att stödja flera nivåer av rättigheter. Följande information ska lagras om alla: Förnamn Efternamn Personnummer Telefonnummer Mobilnummer Kortnummer Adress Epost IM Matpreferenser Anmärkning Funktionärer ska även ha följande information: Mottagningsgren (Drifveriet, Doqumenteriet, Dadderiet, Mammeriet(?)) Eventuell n0llegrupp Daddepar Följande ska lagras om n0llan: Favvodaddor [TODO exakt information som ska lagras] 5.3 Biljetthantering [SIMON] Allmänt sett så är det inom detta område viktigt att man har viss säkerhet. T ex bör bara ÖD och SB (ev. resten av titel) kunna ändra bokade biljetter CRUD-funktioner för arrangemang Det måste finnas gränssnitt för att hantera (skapa, ta bort och ändra) arrangemang n0llans köp Först en bild på ett förslag på en vy för daddor när de ska in och registera en såld biljett biljetthantering-n0llegrupp.png Export -funktionaliteten (HTML), alltså där man får ut en lista över alla anmälda i ett format som är användbart att använda för t ex matplanering eller incheckning, kan exempelvis se ut som Anmälda i ovanstående bild. En lågprioriterad funktion skulle kunna vara att låta användaren välja vilken information som ska visas. Kassören vill ha export i något format för att få in det i andra program. Med stor säkerhet CSV (Komma-separerad lista), men kanske även något annat (Prata med Kassören). 5

6 5.3.3 Externa beställningar För att förenkla för de som kanske vill anmäla sig till flera arrangemang bör detta system ha stöd för att spara en användares information. Detta bör ske helt transparent baserat på personnummer. Se bild biljetthantering-extern.png. För att göra PUL glad bör detta vara valbart (Med default nej?). Det ska vara möjligt att välja om mat- och alkoholfrågorna ska vara med, detta för att vissa arr inte är sittningar, och då är dessa frågor inte relevanta. Det bör också finnas stöd för att lägga till Arr-specifika fält. Det bör finnas stöd för generella textfält och mer specifikt definierade andra fält, t ex en select-ruta med årskurs. Det ska vara lätt att lägga till nya fördefinierade fält. Lätt i detta sammanhang kan innebära att man skriver en funktion i valt progammeringsspråk. Det behöver alltså inte finnas något grafiskt gränssnitt för att lägga till nya fördefinerade fält. Se bild biljetthantering-extern-2.png för hur det kan se ut för den externa biljettbokaren och bild biljetthanteringextern-create.png för hur admingränssnittet kan ser ut. Värden från dessa arrspecifika fält behöver inte sparas, däremot ska svaren på mat- och alkoholfrågor sparas. Själva anmälningsformuläret är strikt sett inte en del av detta system, men är så sammanflätat att det tas upp här ändå. Detta anmälningsformulär bör inte använda databasen direkt för att ta hand om anmälningar eller hämta data utan använda någon form av RPC (webservices? REST?) Exportmöjligheter Det ska gå att exportera informationen om beställda/köpta biljetter till ett antal format. För att förenkla avprickning vid entré och för de arrande daddorna vid matproduktion och liknande ska det finnas möjighet att exportera till ett format som lämpar sig för utskrift. [TODO] Kassören vill ha möjlighet att importera informationen från biljettförsäljningar till ekonomisystemet. Det minsta som krävs för detta är export till CSV-format. 5.4 Ansvarsområden & testamenten I detta avsnitt är det viktigt att hålla definitionen på en Mottagning i minnet. En Mottagning innebär alltså ett genomförande av en specifik mottagning ett visst år. Ett ansvarsområde är kopplat till en Mottagning. Alltså finns det ett ansvarsområde vid namn n0llegasque för varje år systemet använts CRUD-funktionalitet för ansvarsområden Det krävs den vanliga CRUD-funktionaliteten för att skapa, hämta, ändra och ta bort ansvarsområden. Detta är något som bara ska vara tillgängligt för titel Visa ansvarsområden Denna vy förtjänar en tydligare beskrivning än bara R i CRUD. Det bör finnas minst två sätt att gruppera listan på, nämligen inte alls och på ansvarig. Inte alls är tämligen självförklarande, bara en lista på ansvarsområden (Se bild ansvarsomrade-visa-lista.png). För exempel på gruppering på ansvarig, se bild ansvarsomrade-visa-grupperad.png Uppläggning av testamenten Ett testamente ska bestå av flera delar. Detta för att göra det möjligt för flera personer att lämna in testamente för samma ansvarsområde i de fall där ett ansvarsområde har flera ansvariga (exempelvis bärbarstillfälledadda och fotoledare -06). 6

7 Detta är den vy som daddor ser när de ska lägga in sina testamenten i systemet. Funktionalitet som borde finnas här är någon enklare form av formatering (Tänk Wiki, Textile), samt instruktioner för hur man använder den. Annars är detta i stort sett en textruta med en spara-knapp. Även editering av testamenten skall stödjas. Detta bör använda samma vy som att skapa ett nytt, och man ska bara kunna editera sina egna testamenten. Det bör gå att markera testamenten som inlämnade tillsammans. På så sätt kan de som jobbat mycket tillsammans och skrivit sitt testamente tillsammans visa detta och på så vis undvika att få titels blåslampor efter sig. Se bild testamente-inlamning-unchecked.png och testamente-inlamning-unchecked.png. [Varför detta? Jag ser ingen poäng] Titel ska ges möjligheten att sätta en deadline för testamenten. Efter denna deadline ska det inte vara möjligt att ändra sitt testamente eller lägga till nytt Översikt över inlämnade testamenten Sidan bör tydligt visa vilka funktionärer som inte lämnat in, och ge möjlighet att se vilka ansvarsområden det gäller. Se bild [BILD testamente-info] Överföring mellan år Eftersom ett ansvarsområde är kopplat till en viss Mottagning och ansvarsområden till stor del är lika mellan olika år ska det finnas funktionalitet för att lätt överföra alla eller valda ansvarsområden till ett annat (godtyckligt) år. 5.5 Utlånade prylar Detta system ska innehålla stöd för att hålla koll på vilka daddor som lånat vilka prylar, och om de lämnat tillbaka prylen. Pryl i detta fallet innebär t ex daddebyxor och första hjälpen-kit. Det finns två sätt att implementera detta, det ena är snyggt och ganska avancerat, det andra är mer snabbt och enkelt. Det snygga sättet är att på något sätt göra det möjligt att specifiera vad som går att låna. Det snabba och enkla är helt enkelt statiskt lägga till det som titel tycker behövs. 6 Milestones Det finns ett par tydliga milestones i systemet. Dessa milestones har i vissa fall hårda deadlines. Dessa är väldigt hårda då det kommer innebära mycket dubbelarbete om systemet inte är klart. Namn Beskrivning Deadline Anmälningar Anmälningsystemet klart PlOsqvik (Ansvarsområden & testamenten klara för Framtiden titel. Lägga in ansvarsområden och testamenten Få ut infodokument med ansvarsområden, testamente och kontaktinfo för tidigare ansvariga i format passande för utskrift. Autentisering klar och titel inlagt i systemet.) Offentliggörandet (Gränssnitt för att hantera funktionärer. Framtiden Överföring från anmälda till funktionär) Jourveckans början (Systemet tillgängligt för funktionärer. Authorization. Framtiden Hantering av arrangemang. Bil- jettbeställningar.) Testamenteinlämning Testamentedatabasen klar för funktionärer Anmälningar I början av januari vill titel börja ta emot riktiga ansökningar. Då måste systemet för detta vara igång. 7

8 Det enda som ska vara klart vid denna milestone är just anmälningssystemet. Det finns inget behov av autentisering eller auktorisering annat än någonting väldigt basic, i stil med htaccess-baserad HTTPautentisering, med ett lösenord som Titel känner till. Det som ska vara klart är: Anmälningssida för intressenter, samt de två olika typer av listor beskrivna i avsnitt 5.1 Det är viktigt att inte göra mer än vad som krävs! 6.2 PlOqsvik Vissa saker måste vara klara till PlOsqvik 6.3 Offentliggörandet Vissa saker måste vara klara tills det att mottagningen offentliggörs. 6.4 Jourveckan Större delar av hela systemet måste vara klart lagom till jourveckan. 6.5 Testamenteinlämning Mottagningen är över för detta år, förutom återlämningsfest, och tills dess vill titel ha in alla testamenten. Därför måste vid det här laget all testamentedatabasfunktionalitet vara klar. 8