uitwerking voltooide (business) reqs. Met coderegelnummers

Onder deze sectie vindt u de uitwerkingen van de requirements/business-logic, en een referenties naar de regelcodes.

Onder deze sectie vindt u de uitwerkingen van de requirements, en een referenties naar de regelcodes. Het is niet gelukt om alles te documenteren, maar ik kan doorverwijzen daar de code-comments aangezien ik hier van plan was om alle business-logic gedetailleerd te omschrijven. Achteraf was dit niet haalbaar, maar tijdens het programmeren is dit enigzins gelukt.

User-side

Registreren + het Registratieproces

De technische kant van het aanmeldingsproces ziet er zo uit:

Een nieuwe gebruiker vult zijn credentials in en selecteert een foto. Wanneer de gebruiker op de "Register-knop" klikt gebeurt het volgende:
Het wachtwoord wordt gevalideerd. Bij een validatieproblemen wordt de pagina herlaad, maar al-ingevoerde data blijft bestaan zodat de gebruiker deze niet opnieuw hoeft in te voeren. Op het wachtwoord na.
De afbeelding wordt geüpload.
De gegevens worden opgeslagen in de database. Het account(Alleen een referentie naar de locatie van de afbeelding wordt opgeslagen in de vorm van tekst.) Om tampering te voorkomen krijgt het account krijgt hier de status: "Disabled" (*betekent dat de gebruiker in deze toestand nog niet kan inloggen met zijn wachtwoord)
Er wordt een email verstuurd met een activeringscode.
Wanneer er op de activeringscode wordt geklikt, verandert de status van deze gebruiker naar "Enabled". (*Deze gebruiker gebruikt dus écht zíjn eigen e-mailadres en kan nu inloggen met zijn wachtwoord)
Er wordt een welkoms-email verzonden met daarin onder andere informatie over gebruik van de site.

View:

MVC Handling - Controller

Services Mailservice

Aanmeldingsproces met Email-bevestiging

korte inleiding..

View:

MVC Handling - Controller

Services

Inloggen/uitloggen (Spring security & sessiebeheer)

korte inleiding..

View:

MVC Handling - Controller

Services

Lijst met alle demo's zien

Hier worden alle Demo's van deze gebruiker opgevraagd. Alleen demo's met de status 'Sent' en 'Rejected' krijgen een notificatie icoontje voor de demo.

View:

MVC Handling - Controller‌

Services

Demo's individueel inzien, afspelen en beoordeling bekijken

View:

Beoordeling bekijken:

Dit is allereerst mogelijk door de juiste db design die is toegepast: De lookup table. De effectiviteit hiervan kun je goed opmerken bij de relatie tussen het beoordelings-bericht en de admin-side die deze berichten kan instellen. Het bericht dat namelijk onder "TEAM HEXAGON" staat is het bericht dat de admin kan instellen voor demo's met de status "In-review" (of in de code: "Pending").

MVC Handling - Controller

Services

Demo's uploaden + met beschrijving

korte inleiding...

View:

Aanmeldingsproces (vanuit admin-side), met Email-bevestiging

Backoffice accounts worden aangemaakt door de Admin-gebruiker. Het registratieproces ziet er als volgt uit: De admin voert de voornaam, achternaam en het e-mailadres van de toekomstige bo-medewerker in. De toekomstige bo-medewerker krijgt een email met daarin een gegenereerde wachtwoord, het account is tot nu toe nog steeds disabled, wat betekent dat je niet kan inloggen zelfs als je het wachtwoord weet. Door gebruik te maken van de activatie-link in de email veranderd de status van het account naar "Enabled". De Bo-medewerker kan nu door middel van het gegenereerde wachtwoord inloggen. De Backofficemedewerker wordt in de mail verzocht meteen het wachtwoord te wijzigen.

Inloggen/uitloggen (authenticatie & autorisatie)

Demo's en hun toestand inzien: In behandeling, afgewezen, doorgestuurd en door welke beoordelaar

Demo's kunnen afspelen

Dit is de "Review-mode". In deze ruimte kan een bo-medewerker kan dankzij het efficiënt ontworpen user experience design snel door een lading demos reviewen.

Onderin heb je de player. Deze is aan de hand van css en javascript aangepast zodat je niet de gewone kale player van de browser hebt. Ik heb hierbij deze audioplayer als start gebruikt en verder aangepast. De grootste aanpassingen omtrend deze audioplayer vind je daarom in static/css/audioplayer bo-side.css

Het audiobestand wordt gevonden door het pad naar de locatie van het bestand. Deze vraag ik op via de entity en hier komt Thymeleaf van pas. In code ziet dat er zo uit:

/templates/bo/reviewmode.html (r. 103)

<audio class="audio" th:src="${demo.audioFile}" th:preload="auto" th:controls="controls" th:autoplay="autoplay">

En in de uiteindelijke DOM model zo:

Je ziet hier ook dat de pagina naar beneden is gescrolled. Als je een stukje naar boven scrolled vind je daar de headerlogo, je naam en de uitlog-knop. De pagina wordt aan de hand van Javascript automatisch naar beneden gescrolled zodat je de "full schreen" ervaring krijgt. Alle elementen in deze sectie zitten namelijk in 1Vh waardoor je ook bij andere schermformaten de "full schreen" ervaring krijgt.

/templates/bo/reviewmode.html (r. 107-113)

<!-- scrolls the page down to fit the screen in review mode -->
<script>
    function myFunction() {
        var elmnt = document.getElementById("scroll");
        elmnt.scrollIntoView();
    }
</script>

Beoordeling kunnen geven

Alle code om een beoordeling te kunnen geven zit allemaal verstopt in deze knop.

Wanneer een demo voor het eerst wordt geüpload krijgt het de status "Pending". En hier in de review-mode is het punt waar hierin verandering komt. Er zit veel complexe code achter de "Next Demo" knop.

Allereerst, het geheim is dat dit een html form is met daarin radiobutton tags die de informatie dragen voor de post:

Wanneer een bo-gebruiker zijn selectie heeft gemaakt en op "Next Demo" klikt, gebeuren de volgende events die worden opgepakt door DemoController.java (nr. 255-286) :

De gekozen radiobutton wordt opgeslagen in een String variabel: "stateOutcome"
(case:)Als de waarde in "stateOutcome" gelijk is aan "Rejected"
1. verander de state van "Pending" naar "Rejected"
2. voeg de huidig ingelogde in beoordelaar toe aan deze demo als reviewer: "reviewedBy"
3. sla de toestand van deze demo op.
4. verzend een afwijzing-email naar de verzender van deze demo
5. log deze gebeurtenis naar het console
(case:)Als de waarde in "stateOutcome" gelijk is aan "Sent"
1. verander de state van "Pending" naar "Sent"
2. voeg de huidig ingelogde in beoordelaar toe aan deze demo als reviewer: "reviewedBy"
3. sla de toestand van deze demo op.
4. verzend een felicitatie-email naar de verzender van deze demo, regarding doorverwijzing naar Don Diablo.
5. log deze gebeurtenis naar het console
(case: default) Als er iets is misgegaan veranderd er niks en wordt er een log naar het console geschreven dat de state nog steeds "Pending is"
(if:) Als de lijst van "Pending"-demo's meer dan 1 demo bevat
1. vind de id van de volgende demo
2. return een redirect met deze demo-id. Einde.
(else:) Als de lijst met "Pending"-demo's leeg is,
1. redirect naar /review-list. = Verlaat reviewmode. Einde.

Bij het geven van elke beoordeling wordt óók nog eens een email verstuurd naar de verzender/producer met de automatisch ingestelde tekst door de Administrator.

Hier wordt de mailservice geroepen. Deze service doet een aantal dingen. Deze maakt een mime-message aan met verzender, onderwerp en tekst (wat in werkelijkheid een html bestand is) En gebruikt de html templates bij het verzenden van een email. In de email hebben we ook data van de demo nodig, zoals onder andere de verzenders email, naam, artiesten-naam, titel van demo, en de state. Deze informatie kunnen we doorgeven via de "context.setVariable" die werk als een soort "model". Ook in onze e-mailtemplates kunnen we weer thymeleaf gebruiken om de benodigde data op te vragen zodat we een meer gepersonaliseerde emailbericht kunnen verzenden. (/service/MailService.java nr 54 - 76)

De emails worden m.b.v. de @Async annotation verstuurd zodat de hele applicatie niet hoeft te wachten totdat deze taak is volbracht om door te kunnen gaan.

Email pop-up bij geven van positieve beoordeling

Zodra de popup verschijnt dient eenmaal ingelogd te worden met het outlookaccount (van wieweet team hexagon)

View:

Email kunnen verzenden vanuit de applicatie + attachment (Mogelijk naar Don Diablo)

Bij het geven van een posotieve beoordeling moet het team de demo kunne doorZodra de popup verschijnt dient eenmaal ingelogd te worden met het outlookaccount (van wieweet info@hexagon) De ontvanger, het onderwerp, emailbericht en 'bijlage' wordt automatisch ingevuld. Een medewerker kan uiteraard beslissen hier aanpassingen in te maken. Aangezien het niet mogelijk is om met de @mailto: functie daadwerkelijk een bestand in de bijlage mee te sturen vanwege beveiligingsmaatregelen, heb ik besloten in de mail zelf de link naar het audiobestand in onze eigen de server uitgeschreven staan. Zo kan de ontvanger: Don Diablo toch de audiobestanden beluisteren en dat zonder hem éérst zelf te moeten downloaden.

Het grootste voordeel zit natuurlijk bij de backofficemedewerker. Die hoeft nu helemaal niet na te denken bij het goedkeuren van een demo door een email te schrijven, en kan erop vertrouwen dat de computer dat ALTIJD zal regelen.

Wachtwoord wijzigen

Admin-side

Activeringsproces

bij build wordt een wachtwoord gegenereerd die per email naar de admin verzonden wordt. Het account is disabled totdat de activeringscode in de meegestuurde mail gebruikt wordt. De admin wordt bij login meteen doorverwezen naar De admin dient daarna het wachtwoord te wijzigen.

Inloggen/uitloggen (authenticatie & autorisatie)

Systeem-teksten instellen:

Dit zijn de standaard teksten van de beoordelingen.

Databasedesign: Demo, State en Admin (lookup table) De admin kan nu op elk gewenst moment de kolom van "message" aanpassen. Zodat overal bij elke demo (status) het juiste bericht wordt weergegeven

User-side gebruikers inzien en verwijderen

Bo-side gebruikers inzien en verwijderen

Bo-side gebruikers aanmaken

Wachtwoord wijzigen

PreviousFrontend NextSecurity

Last updated 5 years ago

Was this helpful?