Dotnet Applikation

Grupp A

Detta är en MVC-applikation för den administrativa delen av myndigheten, med fokus på Agent- och Operationshantering.

Vi kommer trots checkar och trigger att använda MVC-Applikationen som en "dörrvakt" mot databasen för att inte få databasfel.

Det kommer även att hantera olika rättighter som i nutid stämmer överens med P.U.C.K.O.s beskrivning av myndigheten. Detta främst för att optimera prestandan och inte behöva skicka massa onödiga förfrågningar som databasen kommer att neka.

Allmänna antaganden och kommentarer

När det bland annat kommer till behörighetsnivå har valet gjorts att klassificera med 0,1,2 som är anpassat för framtida skalning. "Vanliga" agenter och Gruppledare får tilldelade behörighetsnivårer, "vanliga" agenter 0 och Gruppledare 1. Admin har behörighetsnivå 2. För att inte riskera säkerheten, kan inte behörighetsnivå 2 tillskrivas någon förutom direkt in i databasen. Behörighetsnivå 0 och 1 tillskrivs agenter beroende på vilken siffra de har. Då ett av kraven för uppgiften var att Gruppledare var de enda som kunde ha nr 0 och högsta siffran en agent kan ha är 99, gjordes antagandet att agent_id ska visas med två siffror. Detta hanterades i databasen som ser till att de som tilldelas siffror mellan 0-9 automatiskt tilldelas siffran 0 före. Alltså kommer gruppledare kunna tilldelas siffrorna 0-9 utan att bryta mot kravet att de är de enda som får ha 0 i sitt agent_id. Självklart kunde man tänkt att varje helt tiotal skulle uppfylla denna logik. Men logiken blev så att sålänge första siffran i agent_id är 0, uppfyller gruppledaren kravet om siffran 0.

Ett annat antagande som gjordes var att skapa en meny i footern (Shared/_Layout.cshtml) för att tydligt orientera sig på MVC_App.

All kod är validerad på W3 Validator och inga error finns.

Requirements

Uppkoppling på wwwlab.webug.se med /Published

• Klart

Agent

Databaskrav

• 1 En agent identifieras av en sammansatt nyckel bestående av första bokstaven i namnet (namn) och ett unikt nummer (nr)(måste hantera två separata fält vid Insert).
• 2 Det finns ett härlett attribut som anger agentens fullständiga namn (förnamn och efternamn).
• 3 Agentnummer 00-09 är reserverade för gruppledare. Agentnummer 10-99 används för övriga agenter (nr 13 får ej förekomma)(Skydd som stoppar användaren från att skriva in nr 13).
• 7 Härlett attribut ska visas i applikationen (agent_id).
• 8 Agentens lön skall ha ett minvärde på 12000kr, ett maxvärde på 35000kr och om ingen lön sätts, ska den automatiskt sättas till 13000kr (valideras i MVC_App-koden).
• 9 Agenter som inte är gruppledare får ej ha lön över 25000kr. (Update/Insert).
• 10 Leif Loket Olsson, Greger puckowitz och Greve Dracula får ej vara agenter (Hanteras via databasen).

Webbkrav (Egna antaganden & Implementation)

• 1 Applikationen ska lista agenter och visuellt presentera det härledda attributet (fullständigt agent_id tavk vare namn och nr) för användaren (databaskrav 7).
• 2 Applikationen ska ha en fritextsökning där användaren kan filtrera och söka efter specifika agenter baserat på deras namn.
• 3 Sökningen ska implementeras via ett självrefererande formulär (postar data till sig själv).
• 4 Vyn för agenthantering och sökning ska vara felfri enligt W3C-validering (inga error).
• 5 Applikationen ska ha ett formulär där systemadministratören kan registrera en helt ny Agent (Insert). Gränssnittet ska hantera databasens begränsningar gällande lönenivåer och otillåtna namn.
• 6 Det ska finnas möjlighet att redigera en befintlig Agent i systemet (Update) och då för att uppdatera lön (uppdatering av databas).

Region

Databaskrav

• 1 En region identifieras unikt av dess namn.
• 3 Det ska gå att härleda regionens antal tidigare incidenter och operationer. (procedur sp_region_statistik).
• 4 Regioner ska kunna hemligstämplas (tas bort temporärt). När detta görs ska regionens befintliga kopplingar till incidenter och operationer automatiskt flyttas till en specifik region som heter 'hemligstämplat'. (Istället för en DELETE via SQL används denna genom att admin klickar på "Ta bort region").

Webbkrav (Egna antaganden & Implementation)

• 1 Applikationen ska presentera regionernas härledda statistik (antal incidenter och operationer) i en överskådlig vy för användaren (databaskrav 3).
• 2 Informationen ska hämtas via ett anrop från applikationen direkt till databasens lagrade procedur och renderas i en standard HTML-tabell.
• 3 Vyn för regionstatistik ska vara felfri enligt W3C-validering (inga error).
• 4 Applikationen ska erbjuda en vy för att filtrera fram regioner. Detta görs via länkning eller en dropdown, där användaren väljer en specifik region (ex. Västra Götaland) och sidan filtrerar om resultatet baserat på detta val (Filtrering/Länkning).
• 5 Det ska finnas möjlighet att radera (hemligstämpla) en region via ett knapptryck i gränssnittet, vilket skickar ett Delete/Update-kommando till databasen (Uppdatering av databas).

Incident

Databaskrav

• 1 Kan identifieras antingen av dess unika namn eller dess unika nummer.
• 2 Incidentens plats ska lagras.
• 3 Incidenten måste inträffa i någon region (tvingande koppling mellan entiteterna).
• 4 Kan ha flera operationer kopplade till sig.

Webbkrav (Egna antaganden & Implementation)

• 1 Applikationen ska lista en standardöversikt av alla incidenter i systemet.
• 2 Applikationen ska visuellt åskådliggöra den tvingande kopplingen mellan Region och Incident för användaren (databaskrav 3).
• 3 Denna koppling ska presenteras med hjälp av en komplex kolumnlayout med en nästlad HTML-tabell, där datan slås ihop och hämtas in via en JOIN.
• 5 Samtliga vyer för incidenter (inklusive den nästlade layouten) ska vara felfria enligt W3C-validering (inga error).

Operation

Webbkrav (Egna antaganden & Implementation)

• 1 Applikationen ska ha en vy förberedd för gruppledare att hantera formulär kopplat mot operationer.