Webgestuurde deelnemersadministratie voor een sociaal...

Toelating tot bruikleen

De auteurs geven de toelating deze masterproef voor consultatie beschikbaar te stellen

en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik

valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de

verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze

masterproef.

The authors give permission to make this master dissertation available for consultation

and to copy parts of this master dissertation for personal use.

In the case of any other use, the limitations of the copyright have to be respected, in

particular with regard to the obligation to state expressly the source when quoting

results from this master dissertation.

6 juni 2011

Tackaert Tessa Prof.dr.ir.W.Philips

Fraeyman Evy Prof. dr. D. Vyncke

Dankwoord

Vooraleer we overgaan tot de eigenlijke scriptie zouden we eerst graag een aantal

mensen willen bedanken die ons geholpen hebben met de realisatie van deze

masterproef en het voltooien van deze richting.

In de eerste plaats willen we prof. Dr. Ir. Wilfried Philips bedanken voor het aanbieden

van dit interessante thesisonderwerp.

Verder willen we onze begeleiders prof. Dr. David Vyncke en dr. Ewout Vansteenkiste

bedanken. Dankzij hen kregen we een duidelijkere kijk op hoe we de scriptie konden

aanpakken en hoe de database opgebouwd moest worden.

We zouden ook onze ouders uitdrukkelijk willen bedanken. Het is dankzij hen dat we

deze opleiding konden volgen. Hun onvoorwaardelijke steun en aanmoedigingen

hielpen ons door de moeilijke momenten heen.

Als laatste willen we alle vrienden bedanken die op een of andere manier bijgedragen

hebben tot het voltooien van deze masterproef. Speciale dank gaat uit naar Merlijn

voor de waardevolle tips en naar Lindsey voor de catering.

Wij wensen u allen veel leesgenot.

Tessa & Evy

Universiteit Gent

Faculteit Ingenieurswetenschappen en Architectuur

Vakgroep Telecommunicatie en Informatieverwerking

Masterproef ingediend tot het behalen van de academische graad van Master

in de Toegepaste informatica

Academiejaar 2010-2011

Ontwerp van een webgestuurde deelnemersadministrati e voor een

sociaal-toeristische jeugdvereniging in Drupal

Evy Fraeyman, Tessa Tackaert

Promotor: prof. dr. ir. Wilfried Philips

Begeleider: prof. dr. David Vyncke, dr. Ewout Vansteenkiste

Samenvatting

Bizon vzw is een sociaal-toeristische jeugdvereniging die activiteiten organiseert voor

maatschappelijk kwetsbare kinderen en jongeren. Het inschrijven van jongeren voor

activiteiten dient echter op een vlotte en efficiënte manier te kunnen gebeuren. Alle

benodigde gegevens dienen dus op een gestructureerde manier te worden

bijgehouden. In deze scriptie ontwerpen we een degelijke database om de data bij te

houden en een gebruiksvriendelijke web-interface die de medewerkers van Bizon

toelaat om gegevens toe te voegen, te bekijken, te wijzigen of te verwijderen. Deze

web-interface zal ontwikkeld worden met Drupal.

Het resultaat is terug te vinden op http://bizonvzw.ugent.be

Trefwoorden: CMS, Drupal, website, Bizon

Inhoud

1. INLEIDING 1

1.1 Probleemstelling en doelstellingen 1

1.2 Content Management Systems 2

1.3 Drupal 3

1.3.1 Algemeen 3

1.3.2 Basisvereisten 4

1.3.3 Veiligheid 4

1.3.4 De Drupal Core 4

1.3.5 De Bizon website 6

1.3.6 Toegangsrechten 6

2. DE DATABASE 8

2.1 Informatievergaring 8

2.1.1 Domeinanalyse 8

2.1.2 Functionele analyse 9

2.1.3 Behoefteanalyse 11

2.2 Conceptueel ontwerp 11

2.3 Logisch ontwerp 14

2.3.1 Stap 1: Omzetten van reguliere entiteittypes 14

2.3.2 Stap 2 tot en met stap 5 15

2.3.3 Stap 6: Omzetting van binaire ‘één-op-meerdere’ relatietypes 15

2.3.4 Stap 7: Omzetting van binaire ‘meerdere-op-meerdere’ relatietypes 16

2.3.5 Stappen 8 en 9 16

2.3.6 Het relationeel databaseschema 17

2.4 Fysiek ontwerp 18

3. ALGEMEEN 24

3.1 De internetbrowser 24

3.2 Template 24

3.3 Gebruikersregistratie 25

3.4 De homepage 25

3.4.1 Anonieme gebruikers 25

3.4.2 Geverifieerde gebruikers 26

3.4.3 Gebruikers met de rol van administrator 26

4. INHOUDSTYPES 27

4.1 Modules 27

4.1.1 Content Construction Kit (CCK) 27

4.1.2 Unique Field 30

4.1.3 Date 31

4.1.4 Token 31

4.1.5 Rules 31

4.2 De verschillende inhoudstypes 32

4.2.1 Inhoudstype ‘Voorzieningen’ 32

4.2.2 Inhoudstype ‘Jongeren’ 36

4.2.3 Inhoudstype ‘Activiteit’ 37

4.2.4 Inhoudstype ‘Inschrijving’ 38

4.2.5 Inhoudstype ‘Onkosten’ 39

4.2.6 Inhoudstype ‘Transport’ 40

4.2.7 Inhoudstype ‘Aanvraag’ 41

4.2.8 Inhoudstype ‘Algemene Gegevens’ 42

5. DE GEGEVENSBANK 43

5.1 Modules 43

5.1.1 Views 43

5.1.2 Views Bulk Operations 44

5.2 Activiteiten 44

5.2.1 Overzicht 44

5.2.2 Filters ter beschikking van de gebruiker 44

5.2.3 Detail, bewerken en verwijderen 44

5.3 Aanvragen 45

5.3.1 Overzicht 45



5.4 Inschrijvingen 48

5.4.1 Overzicht 48



5.5 Jongeren 50

5.5.1 Overzicht 50



5.6 Transportinfo 51

5.6.1 Overzicht 51



5.7 Voorzieningen 51

5.7.1 Overzicht 51



5.8 Onkosten 52

5.8.1 Overzicht 52


6. INHOUD TOEVOEGEN, VERWIJDEREN OF WIJZIGEN 54

6.1 Inhoud toevoegen 54

6.1.1 Activiteiten toevoegen 54

6.1.2 Aanvragen toevoegen 55

6.1.3 Inschrijvingen toevoegen 55

6.1.4 Jongeren toevoegen 55

6.1.5 Transportinfo toevoegen 56

6.1.6 Voorzieningen toevoegen 56

6.1.7 Onkosten toevoegen 57

6.2 Inhoud verwijderen 57

6.3 Inhoud wijzigen 58

7. GEBRUIKERS 59

7.1 Modules 60

7.1.1 Role Delegation 60

7.1.2 Administer Users by Role 60

7.1.3 Password Change Confirm 60

7.1.4 Generate Password (Genpass) 61

7.1.5 Password Strength 62

7.1.6 Profile Permission 63

7.1.7 Restrict Password Change 63

7.1.8 Protect Critical Users 63

7.1.9 Profile 63

7.2 Een gebruiker toevoegen 64

7.3 Gebruikersgegevens wijzigen 65

7.3.1 Geverifieerde gebruikers 65

7.3.2 Administrators 66

7.3.3 Een nieuw wachtwoord aanvragen 67

7.4 Een gebruiker verwijderen 67

8. BESLUIT 68

9. REFERENTIES 69

9.1 Boeken

9.2 Werkstukken

9.3 Websites

Gebruikte afkortingen

Aanvraagid Id van een aanvraag

Aid AcitiviteitID

CCK Content Construction Kit

CMS Content Management System

CSS Cascading Style Sheets

EER Enhanced Entity-Relationship

HTML HyperText Markup Language

Iid InschrijvingsID

IIS webserver Internet information webserver

Jid JongerenID

Mb Megabyte

Nid nodeID

Oid OnkostenID

PHP Hypertext Preprocessor

ProcMedAnn Percentage bij medische annulatie

Rekeningnr Rekeningnummer

SQL Structured Query Language

Telefoonnr Telefoonnummer

Tid TransportID

URL Uniform Resource Locator

Vid RevisionID (Drupal)

Vid VoorzieningsID (inhoudstype)

XHTML Extensible Hypertext Markup Language

Lijst van gebruikte figuren

Figuur 1: EER Diagram p.11

Figuur 2: Het Fysiek ontwerp zoals men zou verwachten p.20

Figuur 3: Het Fysiek ontwerp p.21

Figuur 4: Detail van de velden die in verschillende inhoudstypes voorkomen

en slechts één keer worden opgeslagen in een aparte tabel p.22

Figuur 5: De header voor anonieme gebruikers p.24

Figuur 6: De header voor geverifieerde gebruikers p.25

Figuur 7: De header voor administrators p.25

Figuur 8: Detail en bewerken van een activiteit p.45

Figuur 9: Webpagina met het overzicht van de aanvragen p.47

Figuur 10: Webpagina om een jongere toe te voegen p.55

Figuur 11: Sterk wachtwoord p.65

1

1. Inleiding

1.1 PROBLEEMSTELLING EN DOELSTELLINGEN

De bedoeling van onze scriptie was het ontwikkelen van een deelnemersadministratie-

systeem voor Bizon vzw, een sociaal-toeristische jeugdvereniging. Bizon vzw

organiseert het hele jaar door activiteiten en weekends voor maatschappelijk

kwetsbare kinderen en jongeren. In de schoolvakanties worden deze activiteiten verder

uitgebreid met vakantiekampen. Om al deze activiteiten, jongeren en inschrijvingen op

een overzichtelijke manier te kunnen bijhouden is een betrouwbare database en een

duidelijke gebruikersinterface van cruciaal belang. Momenteel maakt men reeds

gebruik van een systeem die het mogelijk maakt deze variëteit aan gegevens te

beheren, maar men is toe aan een up-to-date systeem dat minder log is als het huidige

met een grotere gebruiksvriendelijkheid. Daarenboven zou het handig zijn als het

nieuwe systeem organisaties toelaat zelf een aanvraag tot inschrijving in te dienen.

Deze aanvraag kan vervolgens door medewerkers van Bizon worden bekeken en

indien geldig aanvaard worden, zonder dat men alle gegevens nog manueel moet

invoeren.

Om tegemoet te komen aan deze verschillende behoeften was er dus nood aan een

nieuwe database waarin gegevens via een webinterface kunnen worden opgeslagen,

gewijzigd en verwijderd. Wij zijn vorig jaar met deze scriptie gestart en hebben samen

met een andere groep een database opgesteld. Deze andere groep heeft deze

database reeds geïmplementeerd in een webgestuurd administratiesysteem

geschreven in PHP (Schelstraete & Jacobs, 2010). Dit jaar werken wij verder met de

database die wij samen met hen ontwikkeld hebben, maar zullen deze op een heel

andere manier implementeren.

Alvorens verder in te gaan op deze implementatie is het belangrijk om de vereiste

functionaliteiten nog wat verder te verduidelijken. Vooreerst is het belangrijk om aan te

halen dat deze website hoofdzakelijk gebruikt zal worden voor administratieve

doeleinden. Wanneer mensen informatie over Bizon of over de georganiseerde

activiteiten wensen kunnen zij nog steeds terecht op de officiële website van Bizon

(www.bizonvzw.be). Voor de administratie is het belangrijk om jongeren te kunnen

inschrijven voor een activiteit. Om deze actie mogelijk te maken dient het dus mogelijk

te zijn om activiteiten, jongeren en informatie met betrekking tot het vervoer van en

naar de activiteit, toe te voegen.

2

Verder behoort een jongere ook steeds tot een bepaalde voorziening. De administratief

medewerkers moeten dus de voorziening, waartoe een bepaalde deelnemer behoort,

kunnen toevoegen. Deze verschillende entiteiten dienen vanzelfsprekend te kunnen

gewijzigd of verwijderd worden. Naast het bewerken van de database dienen

medewerkers natuurlijk ook een duidelijk overzicht te hebben van elk van deze

entiteiten. Bijvoorbeeld welke jongeren er reeds deelnamen aan een Bizon-activiteit,

wie ingeschreven is voor welke activiteit, hoe die jongeren zich van en naar de activiteit

verplaatsen,…

De webapplicatie die hiervoor gecreëerd wordt staat op een openbare website,

waardoor het noodzakelijk is om deze veelheid aan data af te schermen van het grote

publiek. Een voorziening die reeds klant is bij Bizon dient evenwel de mogelijkheid te

hebben om een aanvraag tot inschrijving in te dienen.

1.2 CONTENT MANAGEMENT SYSTEMS

Zoals zonet al werd aangehaald, hebben wij deze website op een heel andere manier

geïmplementeerd dan de vorige groep. Zij maakten gebruik van HTML voor de lay-out

en van PHP om de pagina’s dynamisch te maken. Gezien de doelstellingen leek het ons

echter een goed idee om een content management systeem (CMS) te gebruiken voor

het opbouwen van dynamische webpagina’s. Een CMS laat verschillende gebruikers

met verschillende rechten toe om inhoud aan de website toe te voegen zonder dat zij

daarvoor de technische expertise moeten hebben. Verder is er een duidelijke scheiding

tussen de site-inhoud en de presentatie ervan. De site krijgt hierdoor heel eenvoudig

een consistent beeld doorheen de verschillende pagina’s en men kan de site een

andere look geven zonder dat dit een invloed heeft op de inhoud. Samengevat laat een

CMS systeem de gebruiker toe zich te concentreren op inhoud en biedt het een goed

uitgewerkt gebruikersbeheer, een lay-out die losstaat van de inhoud en uitgebreide

basisfuncties die geen aangepaste codering vergen. In navolging van het verzoek van

de organisatie van Bizon vzw hebben wij ervoor gekozen om bij deze website gebruik

te maken van het open source content management systeem Drupal.

3

1.3 DRUPAL

1.3.1 Algemeen

De basis van Drupal werd in het jaar 2000 gelegd door de Belg en voormalig UGent

student Dries Buytaert. Hij is vandaag nog steeds de projectleider van deze

snelgroeiende open-source CMS. Een uitgebreide internationale gemeenschap draagt

bij tot de verdere ontwikkeling van de Drupal core alsook de ontwikkeling van nieuwe

modules, templates en documentatie. Hierdoor blijft Drupal groeien en kent het een

stijgende populariteit. Vele commerciële organisaties (bv. IKEA), overheids-

gerelateerde instanties (bv. Witte huis) of individuele personen (bv. Robbie Williams)

creëren hun website reeds met Drupal.

Drupal is een modulair opgebouwd systeem. Een bepaalde functionaliteit dient dan ook

gerealiseerd te worden met behulp van een bepaalde module. Opdat de modules

zouden kunnen samenwerken wordt in Drupal gebruik gemaakt van hooks. Een

functionaliteit die in de ene module reeds aanwezig is kan dus ook vanuit een andere

module opgeroepen worden door gebruik te maken van deze hooks. Op deze manier

haakt elke Drupal module in een andere om zo elke functionaliteit van de website te

kunnen realiseren.

Bij de installatie van Drupal download je de Drupal Core. Met deze basisinstallatie kan

je reeds een eenvoudige website maken, content toevoegen, gebruikers en rollen

toevoegen en je site opmaken. Bij deze installatie worden standaard een aantal

modules meegeleverd die onder andere een aantal van bovenstaande functionaliteiten

mogelijk maken. Ook worden er standaard een aantal templates meegeleverd

waardoor je site vanaf het begin een bepaald uitzicht meekrijgt. Daarna kan je Drupal

eenvoudig uitbreiden door andere modules en templates te installeren op de server.

Deze modules en templates kan je onder andere downloaden op drupal.org.

Drupal kent een steile leercurve, maar eens je je de basisprincipes voldoende eigen

gemaakt hebt zijn de mogelijkheden eindeloos. Om met Drupal te leren werken hebben

wij vooral de officiële Drupal-website geraadpleegd (drupal.org) maar ook de boeken

van Van Dyk (2008), Mercer (2010) en Townsend & Pakrul (2010).

4

1.3.2 Basisvereisten

Een eerste basisvereiste is dat er voldoende schijfruimte op de webserver aanwezig is.

Wanneer je gebruik maakt van verschillende modules en een aantal templates kan

deze vereiste schijfruimte gauw oplopen tot 40Mb of meer, de inhoud van de database

niet meegerekend. De aanbevolen webserver is Apache, hoewel het ook mogelijk is

om een IIS webserver te gebruiken. De database server die aanbevolen wordt is

MySQL maar ook hier zijn er andere mogelijkheden. Verder dient php geïnstalleerd te

worden op de server, met een minimale versie van 4.4.0 voor Drupal 6.

1.3.3 Veiligheid

Qua veiligheid scoort Drupal erg goed en werd het veiliger bevonden dan andere

bekende open source CMS platformen zoals Joomla en WordPress. Men heeft een

aangepast beleid ontwikkeld waar mogelijke veiligheidsproblemen onderzocht worden,

geverifieerd en indien nodig gerapporteerd. Een veiligheidsteam is in continue

samenwerking met de Drupal gemeenschap om deze veiligheidsproblemen op te

lossen. Gebruikers worden aangeraden zich te registreren voor de veiligheidsemails

zodat zij op de hoogte blijven van de laatste adviezen met betrekking tot veiligheid.

Wanneer een nieuw veiligheidsupdate beschikbaar is wordt elke beheerder hiervan op

de hoogte gebracht via een waarschuwing op de website.

1.3.4 De Drupal Core

Zoals eerder vermeld worden een aantal modules meegeleverd bij de eerste Drupal

installatie. Een aantal van deze modules zijn optioneel. Andere zijn vereist opdat het

systeem zou werken. Om de verdere uiteenzetting te kunnen volgen is het van belang

deze modules kort toe te lichten.

A. Verplichte core-modules

• Block

Deze module beheert de blokken informatie die rondom de hoofdinhoud kunnen

weergegeven worden. Hierdoor wordt het mogelijk om bijvoorbeeld menu’s weer te

geven in de header of het login-gedeelte eenvoudig rechts te plaatsen van de inhoud.

5

• Filter

Deze module behandelt het filteren van inhoud voordat die getoond wordt. Tekst die

door gebruikers wordt ingevoerd wordt verwerkt via de ingestelde invoerformaten.

Deze invoerformaten gebruiken filters om tekst te bewerken. Hierdoor kan de

gebruikersinvoer omgevormd worden en kan hier informatie aan toegevoegd of

verwijderd worden. De beschikbare invoerformaten zijn filtered HTML, full HTML of PHP

code.

• Node

Deze cruciale module biedt gebruikers de mogelijkheid om inhoud aan de website toe

te voegen en weer te geven op bepaalde pagina’s. Alle inhoud wordt in Drupal

behandelt als een node. Met deze module kunnen de inhoudstypes van de nodes

beheerd worden. Standaard is het in Drupal mogelijk om een node met inhoudstype

pagina (page) of artikel (story) toe te voegen. Deze module laat echter toe om zelf

nieuwe inhoudstypes aan te maken. Kort samengevat maakt deze module het mogelijk

om inhoud toe te voegen, inhoudstypes aan te maken, de inhoud te beheren, revisies

aan te maken, en gebruikerstoegangen met betrekking tot de inhoud in te stellen.

• System

De system-module beheert de algemene instellingen van de website voor beheerders

zoals bijvoorbeeld de algemene gegevens van de website en de statusrapportage.

• User

Deze module beheert het inlogsysteem en de gebruikersregistraties. Dankzij deze

module kan aan elke gebruiker een bepaalde rol en bepaalde toegangsrechten worden

toegekend. Standaard zijn er in Drupal naast de super-user twee soorten rollen

beschikbaar, namelijk anonieme gebruiker en geverifieerde gebruiker. De rol van

anonieme gebruiker spreekt voor zich en groepeert de gebruikers die niet geregistreerd

zijn op de Bizon website. In ons geval behoort de surfer die toevallig op de website

belandt tot deze rol, maar ook de voorzieningen die een aanvraag wensen in te dienen.

De rol van geverifieerde gebruiker groepeert de gebruikers die over een

gebruikersnaam en paswoord beschikken. Tot deze rol behoren dus de administratief

medewerkers van Bizon die toegang moeten hebben tot de inhoud, maar geen

toegang mogen krijgen tot andere gebruikersprofielen uitgezonderd dat van zichzelf.

6

Het was dus noodzakelijk nog een derde rol aan te maken, namelijk deze van

administrator. Gebruikers met deze laatste rol hebben dezelfde rechten als de

geverifieerde gebruikers, maar hebben daarenboven ook toegang tot de

gebruikersprofielen van alle gebruikers. In het hoofdstuk over de gebruikers gaan we

verder in op de specifieke verschillen tussen deze rollen.

1.3.5 De Bizon website

We hebben ervoor gekozen om Drupal 6 te gebruiken. Deze versie is momenteel het

meest gedocumenteerd en daarenboven zijn de meeste beschikbare modules enkel

stabiel voor deze versie. Voor het maken van onze website hebben we gebruik

gemaakt van beschikbare modules op drupal.org. Eigen modules creëren bleek niet

nodig. Wel hebben we sommige modules aangepast zodat ze voldeden aan onze

specifieke behoeften door bijvoorbeeld een extra functie te schrijven. Alle bijkomende

modules werden in een aparte map geplaatst (sites/default/modules). Dit zorgt ervoor

dat bij een eventuele update van de Drupal core de bijkomende modules niet

veranderd worden en nog steeds naar behoren functioneren.

Verder hebben we ervoor gezorgd dat de website met schone URL’s werkt. Dit zorgt

voor een nette URL en vergemakkelijkt het navigeren tussen de verschillende

webpagina’s.

1.3.6 Toegangsrechten

De super-user beschikt in Drupal over een Beheer-navigatie menu. Hier kan men

bijvoorbeeld extra rollen aanmaken voor gebruikers alsook de toegangsrechten

instellen. Deze laatste pagina laat toe om voor elk inhoudstype te bepalen welke

gebruikersrollen nodes van een bepaald inhoudstype mogen zien, aanmaken,

verwijderen of wijzigen. Zo mogen geverifieerde gebruikers geen aanvraag aanmaken,

maar wel bekijken of wijzigen. Per veld afzonderlijk kan men verder verfijnen welke

rollen toegang krijgen tot een bepaald veld. Zo zijn er bepaalde velden van het

inhoudstype aanvraag niet zichtbaar voor anonieme gebruikers. Deze extra velden

werden toegevoegd om de aanvraag later als een inschrijving te kunnen behandelen.

Een goed gebruik van de toegangsrechten pagina bevordert de

gebruiksvriendelijkheid, maar ook de veiligheid van de website.

7

In deze inleiding hebben we kort de probleemsituatie en de te implementeren

oplossingen besproken. Verder hebben we besproken wat Drupal precies is en hoe het

systeem werkt. In de volgende hoofdstukken wordt allereerst de opbouw van de

database verder toegelicht om daarna over te gaan naar de specifieke opbouw van de

website en zijn bijzonderheden.

8

2. De database

De kernfunctionaliteit van deze website bestaat uit de mogelijkheid van het ingeven

van nieuwe informatie enerzijds en het op een gestructureerde manier ophalen en

weergeven van de ingegeven informatie anderzijds. Om dit op een efficiënte en

overzichtelijke manier te verwezenlijken is er nood aan een goed functionerende

database1. Het databaseontwerp is een heel belangrijke schakel in het opzetten van

een nieuwe database. Daarom hebben wij ervoor gekozen om de verschillende fasen

van het databaseontwerp te volgen zoals die staan beschreven in Principes van

databases (De Tré, 2007).

Het volledige databaseontwerpproces bestaat uit vier fases, zijnde de

informatievergaring, het conceptueel ontwerp, het logisch ontwerp en tenslotte het

fysieke ontwerp.

2.1 INFORMATIEVERGARING

In deze fase gaan we na wat de vereisten zijn die aan de database gesteld zullen

worden, met andere woorden welke data er in de database ingevoerd zullen worden,

wat de juiste betekenis en context is van deze data en tenslotte hoe die verschillende

gegevens gerelateerd zijn aan elkaar. Deze informatie werd verkregen door

verschillende samenkomsten met de begeleiders van deze masterproef. Om deze

informatieverzameling op een gestructureerde manier te laten verlopen maken we

achtereenvolgens een domeinanalyse, een functionele analyse en tot slot een

behoefteanalyse op.

2.1.1 Domeinanalyse

In deze fase gaan we vooral na welke informatie in de database zal moeten

gerepresenteerd worden alsook de juiste betekenis en context van deze data. Uit de

verzamelde informatie bleek dat de verschillende gegevens gegroepeerd konden

worden rond een aantal kernconcepten. Hierna volgt een opsomming van deze

concepten, samen met hun specifieke eigenschappen.

1 De database die werd gebruikt voor deze website is grotendeels gebaseerd op de database die wij vorig jaar samen met de andere groep maakten.

9

- Activiteit: De gegevens van een activiteit bestaan uit de naam, de begin- en

einddatum, de annulatiedatum, de locatie, het soort activiteit, de prijs en het

eventuele percentage van terugbetaling bij een annulatie omwille van medische

redenen.

- Jongere: De naam, de geboortedatum, het geslacht, een eventueel persoonlijk

telefoonnummer en de voorziening waarbij de jongere geregistreerd is, moeten

worden bijgehouden.

- Inschrijving: Bij een inschrijving moet eerst en vooral worden bijgehouden welke

persoon zich inschrijft voor welke activiteit, de datum, de prijs, de eventuele

beschikking over een medische fiche en of de jongere toestemming heeft om

naar het buitenland te gaan. Er moet ook ruimte zijn voor de medewerkers van

Bizon vzw om extra opmerkingen toe te voegen. Daarnaast is het echter ook

heel belangrijk dat een eventuele annulatie kan worden bijgehouden, of deze

annulatie omwille van medische redenen is en ten slotte of de annulatie

gebeurde voor de gestelde annulatiedatum.

- Onkosten: Bij onkosten moet voor elke inschrijving worden bijgehouden welk

bedrag nog extra moet worden betaald en er moet ruimte zijn om te

verduidelijken waarvoor dit extra bedrag betaald moet worden.

- Transport: Om het transport op een efficiënte manier bij te houden werd

gevraagd om voor elke activiteit bij te houden hoe de jongeren naar de activiteit

en terug zullen reizen alsook wie hen daarbij zal begeleiden.

- Voorziening: De gegevens van een voorziening bestaan uit de naam en het

adres van de voorziening en het telefoonnummer van de verantwoordelijke.

Optioneel moet men ook de naam en het e-mailadres van de verantwoordelijke

kunnen bijhouden evenals om welke soort voorziening het gaat. Men moet

kunnen aanduiden of er aan de voorziening een korting wordt toegekend, of de

voorziening verborgen wordt binnen de database, of er jongeren zijn die ouder

zijn dan 18 jaar en ten slotte moet er ruimte zijn om bijkomende informatie in te

geven.

2.1.2 Functionele analyse

Bij de functionele analyse gaan we na waar de informatie vandaan komt en hoe deze

zal worden verwerkt. De herkomst van de gegevens is duidelijk: deze zullen in de

database worden ingevoerd door medewerkers van Bizon vzw. Er is echter één

uitzondering op deze regel en die vinden we terug bij het concept inschrijving.

10

Enerzijds is het mogelijk dat een inschrijving wordt ingegeven door een medewerker

van Bizon vzw maar anderzijds moet het ook mogelijk gemaakt worden voor een

voorziening om zelf een inschrijving in te geven. Deze laatste inschrijving is echter op

bepaalde punten verschillend van een inschrijving ingegeven door een medewerker,

het is namelijk eerder een aanvraag tot inschrijving. Praktisch gezien betekent dit dat

deze gegevens pas aan de inschrijvingen mogen worden toegevoegd nadat ze zijn

goedgekeurd door een medewerker van Bizon vzw. Medewerkers kunnen verder ook

aangeven of een bepaalde inschrijving werd geannuleerd en of de jongere werd

vervangen.

Bij de gegevens van de jongeren zelf moet de voorziening regelmatig worden

aangepast, gezien uit de praktijk blijkt dat jongeren vaak van de ene voorziening naar

de andere verhuizen. Ook het telefoonnummer dient al eens aangepast te worden. De

overige gegevens blijven normaalgezien ongewijzigd.

Een aantal activiteiten worden jaarlijks herhaald, deze moeten niet vaak aangepast

worden (het moet echter zeker mogelijk zijn). Voorts worden activiteiten die reeds

plaatsgevonden hebben niet uit de database verwijderd.

De informatie omtrent transport moet worden bijgehouden per voorziening en activiteit.

Dit betekent dat alle jongeren van dezelfde voorziening die naar dezelfde activiteit

gaan zich op dezelfde manier van en naar de locatie verplaatsen.

Per inschrijving moet het mogelijk zijn om één of meerdere onkostennota’s toe te

kennen.

De gegevens van de voorzieningen moeten kunnen aangepast worden, dit is vooral

belangrijk voor de naam, het e-mailadres en het telefoonnummer van de

verantwoordelijke.

Verder kwam aan het licht dat er ook ruimte voorzien moet worden om de algemene

gegevens van Bizon vzw in de database op te nemen. Het mag enkel mogelijk zijn voor

iemand met de juiste bevoegdheid om deze gegevens aan te passen.

In principe worden ook de inloggegevens toegevoegd aan de database. Gezien

hiervoor reeds een tabel aanwezig is in de database van Drupal, zullen wij geen extra

tabel voor inloggegevens toevoegen.

11

2.1.3 Behoefteanalyse

Uit het voorgaande blijkt dat, naast de zes oorspronkelijk gedefinieerde kernconcepten,

er nood is aan een aantal bijkomende concepten. Deze omvatten een mogelijkheid

voor voorzieningen om een aanvraag tot inschrijving in te geven, het opslaan van de

algemene gegevens van Bizon vzw en tot slot het beveiligen van de website.

Het mag enkel voor reeds geregistreerde voorzieningen mogelijk zijn om een aanvraag

tot inschrijving in te dienen. Bij een aanvraag moet dus eerst en vooral de voorziening

waar de jongere toe behoort opgegeven worden en de naam van de activiteit waarvoor

de jongere zich wil inschrijven. Voorts moeten er voldoende gegevens worden

meegegeven over de jongere zelf. Indien de jongere nog niet eerder ingeschreven was

voor een activiteit bij Bizon vzw kan deze door middel van deze gegevens eerst

worden geregistreerd. Bij een aanvraag zal men dus (net als bij het concept jongere)

de naam, de voornaam, het geslacht en de geboortedatum van de jongere moeten

invullen met eventueel nog een telefoonnummer van de jongere.

Het concept algemene gegevens moet de naam van de verantwoordelijke, het adres,

het telefoonnummer en het rekeningnummer van Bizon vzw bevatten.

Voor het beveiligen van de website zal aan de gebruikers een unieke gebruikersnaam

worden toegekend waaraan een paswoord verbonden is. Zoals reeds vermeld zullen

wij hiervoor geen extra tabel aanmaken, gezien gebruikers reeds door Drupal zelf

worden beheerd. Het is een vereiste dat naast de gebruikersnaam en het paswoord

ook de naam, voornaam, e-mailadres en de eventuele administratorrechten van de

gebruiker worden bijgehouden.

2.2 CONCEPTUEEL ONTWERP

In deze fase ontwerpen we een conceptueel model (een abstracte voorstelling van de

database) op basis van de informatie die we verzameld hebben in de voorgaande fase.

Het is echter van enorm belang dat dit model losstaat van enig ander databasemodel

of datamodel van een applicatie. Indien dit niet zo zou zijn loopt men immers het

gevaar dat de database in dit stadium reeds te sterk gekoppeld wordt aan een bepaald

model of applicatie, wat nadelig kan zijn voor de algemene bruikbaarheid van de

database.

In het model zullen de reeds gevonden kernconcepten met hun eigenschappen en

onderlinge relaties visueel voorgesteld worden. De representatietechniek die we

hiervoor gebruiken is het ‘Enhanced Entity-Relationship’-diagram (EER-diagram) dat

12

wordt opgebouwd volgens de voorschriften van het ‘Enhanced Entity-Relationship’-

model (EER-model) zoals gesuggereerd in ‘Principes van databases’ (De Tré, 2007).

Dit model modelleert concepten uit de reële wereld aan de hand van entiteittypes2 en

hun attributen3 enerzijds en verwantschappen tussen entiteittypes (relatietypes)

anderzijds.

Er kunnen zeven entiteittypes worden geïdentificeerd, namelijk Activiteit, Aanvraag,

Inschrijving, Jongere, Onkosten, Voorziening en Algemene gegevens. Alle

entiteittypes, uitgezonderd Algemene gegevens, zijn via verschillende relatietypes met

elkaar verbonden. De 7 entiteittypes en het relatietype Transport worden gekenmerkt

door een aantal attributen. De meeste attributen zijn enkelwaardig4 maar zowel bij

Activiteit, Transport als Voorzieningen komen ook een aantal samengestelde attributen

voor.

Alle identiteittypes moeten op een unieke manier kunnen worden geïdentificeerd. Dit

gebeurt aan de hand van primaire sleutels, deze worden gevisualiseerd door hun naam

te onderstrepen.

Ten slotte worden bij relatietypes twee soorten restricties onderscheiden: de

kardinaliteitsrestricties en de participatierestricties. De Tré (2007) stelt dat de

kardinaliteitsrestrictie een beperking oplegt aan het aantal entiteiten van het entiteittype

dat op een gegeven tijdstip maximaal kan voorkomen in een relatie van het relatietype.

Mogelijke waarden zijn 1 (maximaal één) en N (meerdere).

“De participatierestrictie bepaalt of op elk tijdstip, elke entiteit van het entiteittype moet

voorkomen in een relatie van het relatietype. Is dit het geval dan spreek men van een

totale participatie van het entiteittype (dubbele verbindingslijn), anders van een partiële

participatie (enkele verbindingslijn)” (De Tré, 2007, p. 65).

Het uiteindelijke schema (Figuur 1) kan worden teruggevonden op de volgende pagina.

2 “Een entiteit is een ‘ding’ dat een zelfstandig bestaan leidt in de reële wereld. Een entiteittype is een collectie van entiteiten en wordt gekenmerkt door een naam en een verzameling van attributen” (De Tré, 2007, p. 62). 3 “De entiteiten die naar voor komen uit de domeinanalyse worden gegroepeerd op basis van gemeenschappelijke karakteristieken, de attributen” (De Tré, 2007, p. 62). 4 “Als een attribuut enkelwaardig is betekent dit dat het attribuut, binnen de context waarin wordt gewerkt, op elk tijdstip slechts één waarde mag aannemen. Samengestelde attributen kunnen, binnen de gegeven context, op elk tijdstip een collectie van (verschillende) waarden aannemen” (De Tré, 2007, p.65).

13

Inschrijving

Iid

Prijs

Datum

Toestemming Buitenland

MedischAttest

Actie

Opmerkingen

Onkosten

Oid Beschrijving

Activiteit

Aid

Prijs Data Annulatiedatum

Aankomst

Vertrek

Naam

Tran- sport

TypeActiviteit

Locatie ProcMedAnn

Tid

Heen

Begeleider

Vervoer

Terug Vervoer

Begeleider

Transport-Opmerkingen

1

n

n

n 1

1

Voorzieningen

Aanvraag

Jongeren

n

Naam Voorziening

Voornaam

Familienaam

Geboortedatum

Telefoonnr

Geslacht

Datum

AanvraagId

n

1 m

Naam

Korting Info

Soort

Verborgen

Oudere Jongeren

Adres

Straat + nr

Postcode

Plaats Provincie Land

Vid

Verantwoordelijke

Telefoonnr

E-mail

naam

1

1 n

Telefoonnr

Geboortedatum

Familienaam

Voornaam Geslacht

Jid

n

Algemene Gegevens

Adres

Verantwoordelijke

Telefoonnr

Uniek Bic

Iban

Rekeningnr Plaats

Bedrag

Figuur 1: EER diagram

14

2.3 LOGISCH ONTWERP

In deze fase wordt een databasemodel gekozen en het databaseschema wordt

opgebouwd. De keuze van het databasemodel is in deze fase normaalgezien

onafhankelijk van het later gekozen databasemanagementsysteem. In dit geval weten

we echter al dat het databasemanagementsysteem voor de website MySQL, een

opensource managementsysteem voor relationele databases, zal zijn (MySQL).

Bijkomend zijn relationele databasemodellen tegenwoordig de standaard in de

industrie. Hierdoor ligt de keuze voor een relationeel databasemodel voor de hand.

Om het EER-diagram om te zetten naar een relationeel databaseschema moeten we

gebruik maken van een omzettingsalgoritme. Dit algoritme bestaat uit negen stappen

(De Tré, 2007).

2.3.1 Stap 1: Omzetten van reguliere entiteittypes

We maken een basisrelatie aan voor elk regulier entiteittype. De attributen van het

entiteittype worden toegevoegd aan de basisrelatie. De primaire sleutel wordt gevormd

door alle attributen uit de sleutel van het entiteittype samen.

(1.0) Activiteit (Aid: integer, Naam: text, TypeActiviteit: enum(‘Eendagsactiviteit’,

‘Weekend’, ‘Kamp’), Annulatiedatum: date, Aankomst: date, Vertrek: date,

Locatie: text, Dagprijs: decimal(10,2), ProcMedAnn: decimal(10,2)).

Primaire sleutel: {Aid}

(2.0) Inschrijving (Iid: integer, Datum: date, Actie: enum(‘Inschrijving’, ’Tijdige

annulatie’, ‘Laattijdige annulatie’, ‘Vervanging’, ‘Medische annulatie’), Prijs:

decimal(10,2), MedischAttest: enum(‘Ja’, ‘Neen’), ToestemmingBuitenland:

enum(‘Ja’, ‘Neen’), Opmerkingen: text)

Primaire sleutel: {Iid}

(3.0) Jongeren (Jid: integer, Voornaam: text, Familienaam: text, Geslacht:

enum(‘v’, ‘m’), Geboortedatum: date, Telefoonnummer: text)

Primaire sleutel: {Jid}

15

(4.0) Voorzieningen (Vid: integer, NaamVoorziening: text, StraatEnNummer: text,

Postcode: integer, Plaats: text, Provincie: text, Land: text,

NaamVerantwoordelijke: text, EmailVerantwoordelijk: text,

TelVerantwoordelijke: text, SoortVoorziening: text, Korting: enum(‘Ja’,

‘Neen’), OudereJongeren: enum(‘Ja’, ‘Neen’), Verborgen: enum(‘Ja’, ‘Neen’),

ExtraInfo: text)

Primaire sleutel: {Vid}

(5.0) Onkosten (Oid: integer, Bedrag: decimal(10,2), Beschrijving: text)

Primaire sleutel: {Oid}

(6.0) Aanvraag (Aanvraagid: integer, NaamVoorziening: text, Voornaam: text,

Familienaam: text, Telefoonnummer: text, Geboortedatum: date, Geslacht:

enum(‘v’, ‘m’), Datum: date)

Primaire sleutel: {Aanvraagid}

(7.0) Algemene gegevens (Uniek: integer, VerantwoordelijkeBizon: text,

StraatNummerBizon: text, PostcodeBizon: integer, PlaatsBizon: text,

TelefoonnummerBizon: text, RekeningNummerBizon: text, IbanBizon: text,

BicBizon: text)

Primaire sleutel: {Uniek}

2.3.2 Stap 2 tot en met stap 5

Deze stappen zijn hier niet van toepassing.

2.3.3 Stap 6: Omzetting van binaire ‘één-op-meerdere’ relatietypes

De primaire sleutel van een entiteittype met kardinaliteit ‘één’ wordt opgenomen als

vreemde sleutel in het entiteittype met kardinaliteit ‘meerdere’.

(2.1) Inschrijving (Iid: integer, Aid: integer, Jid: integer, Datum: date, Actie:

enum(‘Inschrijving’, ’Tijdige annulatie’, ‘Laattijdige annulatie’, ‘Vervanging’,

‘Medische annulatie’), Prijs: decimal(10,2), MedischAttest: enum(‘Ja’,

‘Neen’), ToestemmingBuitenland: enum(‘Ja’, ‘Neen’), Opmerkingen: text)


Vreemde sleutel: {Aid} verwijst naar Activiteit

Vreemde sleutel: {Jid} verwijt naar Jongeren

16

(3.1) Jongeren (Jid: integer, Vid: integer, Voornaam: text, Familienaam: text,

Geslacht: enum(‘v’, ‘m’), Geboortedatum: date, Telefoonnummer: text)


Vreemde sleutel: {Vid} verwijst naar Voorzieningen

(5.1) Onkosten (Oid: integer, Iid: integer, Bedrag: decimal(10,2), Beschrijving:

text)


Vreemde sleutel: {Iid} verwijst naar Inschrijving

(6.1) Aanvraag (Aanvraagid: integer, Vid: integer, Aid: integer, NaamVoorziening:

text, Voornaam: text, Familienaam: text, Telefoonnummer: text,

Geboortedatum: date, Geslacht: enum(‘v’, ‘m’), Datum: date)




2.3.4 Stap 7: Omzetting van binaire ‘meerdere-op-meerdere’ relatietypes

In deze stap maken we voor elk ‘meerdere-op-meerdere’ relatietype een nieuwe

basisrelatie aan. De primaire sleutels van de betrokken entiteittypes worden als

vreemde sleutels toegevoegd aan de nieuwe basisrelatie. De primaire sleutel van de

nieuwe basisrelatie zelf wordt samengesteld uit de attributen van deze vreemde

sleutels. De attributen van het relatietype zelf worden ook toegevoegd.

(8.0) Transport (Tid: integer, Vid: integer, Aid: integer, BegeleiderHeen: text,

VervoerHeen: text, BegeleiderTerug: text, VervoerTerug: text,

TransportOpmerkingen: text)

Primaire sleutel: {Tid}



2.3.5 Stappen 8 en 9

Deze stappen zijn hier niet van toepassing.

17

2.3.6 Het relationeel databaseschema

Het definitieve databaseschema wordt samengesteld uit de recentste versies van de

aangemaakte basisrelaties. In dit geval bestaat dit uit: (1.0), (2.1), (3.1), (4.0), (5.1),

(6.1), (7.0), (8.0).

(1.0) Activiteit (Aid: integer, Naam: text, TypeActiviteit: enum(‘Eendagsactiviteit’,

‘Weekend’, ‘Kamp’), Annulatiedatum: date, Aankomst: date, Vertrek: date,

Locatie: text, Dagprijs: decimal(10,2), ProcMedAnn: decimal(10,2)).

Primaire sleutel: {Aid}

(2.1) Inschrijving (Iid: integer, Aid: integer, Jid: integer, Datum: date, Actie:

enum(‘Inschrijving’, ’Tijdige annulatie’, ‘Laattijdige annulatie’, ‘Vervanging’,

‘Medische annulatie’), Prijs: decimal(10,2), MedischAttest: enum(‘Ja’, ‘Neen’),

ToestemmingBuitenland: enum(‘Ja’, ‘Neen’), Opmerkingen: text)



Vreemde sleutel: {Jid} verwijt naar Jongeren

(3.1) Jongeren (Jid: integer, Vid: integer, Voornaam: text, Familienaam: text,

Geslacht: enum(‘v’, ‘m’), Geboortedatum: date, Telefoonnummer: text)



(4.0) Voorzieningen (Vid: integer, NaamVoorziening: text, StraatEnNummer: text,

Postcode: integer, Plaats: text, Provincie: text, Land: text,

NaamVerantwoordelijke: text, EmailVerantwoordelijk: text,

TelVerantwoordelijke: text, SoortVoorziening: text, Korting: enum(‘Ja’, ‘Neen’),

OudereJongeren: enum(‘Ja’, ‘Neen’), Verborgen: enum(‘Ja’, ‘Neen’), ExtraInfo:

text)

Primaire sleutel: {Vid}

(5.1) Onkosten (Oid: integer, Iid: integer, Bedrag: decimal(10,2), Beschrijving: text)


Vreemde sleutel: {Iid} verwijst naar Inschrijving

18

(6.1) Aanvraag (Aanvraagid: integer, Vid: integer, Aid: integer, NaamVoorziening:

text, Voornaam: text, Familienaam: text, Telefoonnummer: text,

Geboortedatum: date, Geslacht: enum(‘v’, ‘m’), Datum: date)




(7.0) Algemene gegevens (Uniek: integer, VerantwoordelijkeBizon: text,

StraatNummerBizon: text, PostcodeBizon: integer, PlaatsBizon: text,

TelefoonnummerBizon: text, RekeningNummerBizon: text, IbanBizon: text,

BicBizon: text)

Primaire sleutel: {Uniek}

(8.0) Transport (Tid: integer, Vid: integer, Aid: integer, BegeleiderHeen: text,

VervoerHeen: text, BegeleiderTerug: text, VervoerTerug: text,

TransportOpmerkingen: text)

Primaire sleutel: {Tid}



2.4 FYSIEK ONTWERP

Alvorens verder te gaan met het fysieke ontwerp, is het belangrijk om te vermelden dat

ook Drupal zelf nood heeft aan een database om instellingen en inhoud op te slaan.

Vanuit de technische afdeling werd het voor ons mogelijk gemaakt om hiervoor gebruik

te maken van een MySQL-database, via het databasemanagementsysteem

phpMyAdmin. MySQL is een relationele database die gebruik maakt van SQL

(Structured Query Language). PhpMyAdmin verschaft de mogelijkheid om de MySQL

database via het internet te beheren. Beide zijn, evenals Drupal, enorm populaire open

source systemen.

Indien men de database rechtstreeks in phpMyAdmin zou opbouwen verkrijgt men het

schema in Figuur 2. Dit schema werd bijgevoegd als vergelijkingspunt, gezien het

uiteindelijke schema in Drupal (Figuur 3) iets ingewikkelder overkomt en wat meer

uitleg vergt.

De meeste informatie op een Drupal website wordt toegevoegd via inhoudstypes

(content types). Wanneer de informatie opgeslagen wordt creëert Drupal een node die

de ingegeven informatie bevat.

19

Naast de twee standaard inhoudstypes page en story is er ook de mogelijkheid om zelf

een specifiek inhoudstype te definiëren met behulp van de CCK module (Content

Construction Kit). Deze inhoudstypes kunnen worden opgebouwd uit een aantal velden

(fields) met een welbepaald type, bijvoorbeeld: date, text, integer,…

Voor elke basisrelatie die geïdentificeerd werd in de voorgaande fases werd een

inhoudstype aangemaakt. De attributen van een basisrelatie werden aan het

overeenkomstige inhoudstype toegevoegd door gebruik te maken van velden. Voor elk

inhoudstype wordt door Drupal automatisch een tabel (content_type_’naam van het

inhoudstype’) toegevoegd aan de database die de gespecificeerde velden (field_’naam

van het veld’) bevat alsook de kolommen node ID (nid) en revision ID (vid).

Wanneer een node wordt aangemaakt krijgt deze een uniek node ID en een uniek

revision ID. Aanvankelijk hebben ze elk dezelfde integer als waarde. Het verschil is

echter dat het nid nooit verandert maar het vid wel. Telkens wanneer een node bewerkt

wordt, verandert de waarde van vid. In de tabel wordt steeds het vid bijgehouden van

de recentste versie van de node.

Indien we in een inhoudstype een veld aanmaken met als type node referentie kunnen

we het inhoudstype kiezen waarnaar we willen refereren. Dit veld zal dan een

verwijzing maken naar het gekozen nid. Een nid is voor een node dus eigenlijk een

primaire sleutel. Een veld met als type node referentie in het ene inhoudstype gebruikt

de node ID’s uit het andere, gespecificeerde inhoudstype om een relatie te maken

tussen de twee inhoudstypes.

Om het overzicht te behouden hebben we ervoor gekozen om de velden met als type

node referentie de namen Vid, Jid en Iid te geven, zodat het duidelijk is naar welk

inhoudstype ze verwijzen. Voor Aid was dit echter niet mogelijk. Om extra functionaliteit

te kunnen toevoegen werd de node referentie Aid opgesplitst in een aantal

verschillende velden namelijk: content_field_eendagsactiviteit, content_field_weekend

en content_field_kamp. Uiteraard hebben deze velden het type node referentie. Deze

opsplitsing laat het toe om op basis van het gekozen type van activiteit slechts een

selectie van mogelijkheden weer te geven, wat het gebruiksgemak bevordert (dit wordt

verder uitgelegd op p.54).

Vervolgens is het belangrijk om op te merken dat Drupal voor elk veld, dat in meer dan

één inhoudstype wordt gebruikt, een aparte tabel aanmaakt in de database.

Figuur 3 toont de volledige database die werd gebruikt voor het implementeren van de

inhoudstypes en hun velden.

20

Om het overzicht te bewaren hebben we de velden, die in meer dan één inhoudstype

voorkomen en waar in de praktijk een aparte tabel (met als benaming

content_field_’naam van het veld’) voor wordt gemaakt, toch bijgevoegd bij elk

inhoudstype waarin ze voorkomen. Figuur 4 toont deze velden op de manier waarop ze

in de database worden opgeslagen.

Tenslotte zijn er in sommige inhoudstypes extra velden toegevoegd die niet aanwezig

waren in de vorige fases van het databaseontwerpproces. Deze zijn tijdens het

ontwikkelen van de website toegevoegd voor het creëren van extra functionaliteit en

zullen later worden besproken.

21

Figuur 2: Fysiek ontwerp zoals men dit zou verwachten

22

Figuur 3: Fysiek ontwerp

Database Drupal met alle velden bij het inhoudstype waarin ze voorkomen.

23

Figuur 4

Detail van de velden die in verschillende inhoudstypes voorkomen en slechts één keer worden opgeslagen in een aparte tabel.

24

3. Algemeen

In dit hoofdstuk lichten we de algemene instellingen van de website toe. Zo bespreken

we met welke browsers de website compatibel is, welke template we gekozen hebben,

hoe gebruikers zich kunnen registreren, en hoe de verschillende rollen zich

onderscheiden.

3.1 DE INTERNET BROWSER

Drupal core sites zijn compatibel met zowat elke browser die CSS en JavaScript

ondersteunt. Er kunnen natuurlijk altijd kleine verschillen zijn in presentatie maar deze

zijn te verwaarlozen. Internet Explorer, Firefox, Opera, Safari, Camino en Google

Chrome ondersteunen de Drupal core programmatie. Onze website kan dus gebruikt

worden voor elk van bovenstaande browsers, maar werd geoptimaliseerd voor Firefox.

3.2 TEMPLATE

Bij Drupal maakt men een duidelijk onderscheid tussen inhoud en vormgeving. De

vormgeving wordt mogelijk gemaakt door templates. De gebruiker krijgt de mogelijk om

bestaande templates te installeren of om er zelf een te schrijven. Wij hebben ervoor

geopteerd om een bestaande template te gebruiken. De templates die beschikbaar zijn

op drupal.org dienen vooraleer deze gedownload kunnen worden een uitgebreid

validatieproces en een veiligheidstest te doorlopen, waardoor de kans op fouten

verkleind wordt. Bij de installatie van Drupal worden standaard een aantal templates

geïnstalleerd met name Bluemarine, Garland, Chameleon, Marvin, Minelli en

Pushbutton. Elk van deze templates geeft de toegevoegde inhoud op een andere

manier weer. Zo worden primaire links bijvoorbeeld bij de ene template links in een

navigatie-blok weergegeven en bij een andere in de header. De template die wij

gekozen hebben is gebaseerd op de Zen-template. Deze populaire template biedt een

basis XHTML template die voldoet aan de standaarden maar die toch toelaat om

belangrijke aanpassingen te doen met behulp van CSS. Wij hebben gebruik gemaakt

van de ‘CTI Flex’-template. Deze Zen-gebaseerde template is nog steeds uiterst

aanpasbaar maar voegt een aantal functies toe. Zo is het bijvoorbeeld mogelijk om de

primaire links als een drop-down menu weer te geven, wat niet mogelijk is in bepaalde

andere templates.

25

3.3 GEBRUIKERSREGISTRATIE

Op de homepage van de bizon website kunnen medewerkers van Bizon zich

aanmelden. Het is echter niet mogelijk om een nieuwe account aan te maken. Gezien

enkel medewerkers van Bizon zich mogen registreren op de site is deze optie

weggelaten. Wanneer een nieuwe account nodig is kan deze enkel worden

aangemaakt door een administrator.

De nieuwe gebruiker krijgt vervolgens een e-mail toegestuurd met zijn of haar

inloggegevens. In het hoofdstuk over de gebruikers zullen we hier uitgebreider op

ingaan.

3.4 DE HOMEPAGE

Aangezien het de bedoeling was om een administratieve site te maken voor het beheer

van Bizon inschrijvingen, is de voorpagina bewust redelijk sober gehouden. De

homepage voor anonieme gebruikers ziet er lichtjes anders uit dan deze voor

geregistreerde gebruikers. Met de module ‘Menu per Role’ kan men instellen welke

menu’s zichtbaar zijn per gebruikersrol. Hierdoor worden menu’s die verwijzen naar

inhoud waar gebruikers, met een bepaalde rol, geen toegang toe hebben niet zichtbaar

voor die bepaalde rol. Dit bevordert de gebruiksvriendelijkheid van de website.

Voor elke geregistreerde gebruiker is er op de homepagina rechts bovenaan een link

voorzien die de gebruiker toelaat zijn persoonlijke gegevens te wijzigen. Deze link

wordt gepresenteerd als de gebruikersnaam van de medewerker.

Naast deze account-link is er een link voorzien die een gebruiker toelaat uit te loggen.

3.4.1 Anonieme gebruikers

Figuur 5: De header voor anonieme gebruikers

Een anonieme gebruiker kan op de website enkel een aanvraag tot inschrijving

indienen. Dit kan via de primaire link ‘inschrijven voor een activiteit’. Deze aanvraag

wordt echter enkel opgenomen in de database wanneer er een geldig klantennummer

ingevoerd werd.

26

3.4.2 Geverifieerde gebruikers

Figuur 6: De header voor geverifieerde gebruikers

Geverifieerde gebruikers krijgen in de header de primaire links te zien die hen helpen

navigeren doorheen de pagina’s. Zo kan men via het drop-down menu

“Gegevensbank” naar de overzichten gaan van de activiteiten, de inschrijvingen, de

aanvragen, de onkosten, de jongeren, de voorzieningen en van de transportinfo.

Via dit zelfde drop-down menu kan men voor elk van deze inhoudstypen ook een node

toevoegen. Geverifieerde gebruikers kunnen geen aanvraag toevoegen, gezien zij

beschikken over de mogelijk om een jongere onmiddellijk in te schrijven.

Naast het menu gegevensbank is er een menu ‘algemene gegevens’. Hier kan men de

algemene gegevens van Bizon vzw bekijken. Gezien dit inhoudstype voor elk veld

slechts één waarde kan hebben is het niet mogelijk om nieuwe algemene gegevens

toe te voegen. Geverifieerde gebruikers kunnen deze gegevens ook niet bewerken.

3.4.3 Gebruikers met de rol van administrator

Figuur 7: De header voor administrators

Gebruikers met de rol van administrator hebben dezelfde rechten en krijgen dus

dezelfde menu’s te zien op de homepage als geverifieerde gebruikers. Administrators

hebben daarentegen nog extra bevoegdheden. Zo krijgen zij, in tegenstelling tot de

gewone geverifieerde gebruikers, de mogelijkheid om de algemene gegevens van

Bizon aan te passen. Verder krijgen administrators nog een extra menu in de header te

zien, namelijk het menu Gebruikers. Via deze link kunnen zij de gebruikers beheren. In

het hoofdstuk over gebruikers zullen we verder toelichten welke functionaliteiten

hiervoor geïmplementeerd werden.

27

4. Inhoudstypes

Zoals reeds eerder vermeld wordt informatie op een Drupal website toegevoegd via

inhoudstypes. Naast de twee standaard inhoudstypes, page en story, is het ook

mogelijk om zelf een specifiek inhoudstype te definiëren. Inhoudstypes bestaan uit een

aantal velden die kunnen worden ingevuld door gebruikers. Met behulp van de CCK

module (Content Construction Kit) worden de mogelijkheden om het type5 van een veld

te bepalen reeds sterk uitgebreid. Toch was er, naast CCK, nood aan enkele extra

modules om de functionaliteit te optimaliseren.

Wanneer men de velden van een inhoudstype invult en deze vervolgens opslaat,

creëert Drupal een node die de ingegeven informatie bevat.

In dit deel bespreken we de inhoudstypes in detail. Eerst bespreken we de modules die

werden gebruikt om de inhoudstypes te creëren. Vervolgens bekijken we per

inhoudstype de functies, de configuratie van de verschillende velden en of eventueel

code toegevoegd werd om extra functionaliteit te bekomen.

4.1 MODULES

4.1.1 Content Construction Kit (CCK)

Deze module is niet standaard aanwezig in de Drupal core en dient dus gedownload te

worden op drupal.org.

De CCK module is eigenlijk een verzameling van kleinere modules die naadloos in

elkaar overvloeien. De primaire module heet ‘Content’, deze dient ingeschakeld te zijn

alvorens men gebruik kan maken van de andere deelmodules. Naast de deelmodules

die aanwezig zijn in de CCK core bestaan er nog veel andere deelmodules die men kan

downloaden indien nodig. In wat volgt bespreken we eerst de gebruikte deelmodules

die reeds aanwezig waren in de CCK core en vervolgens de extra geïnstalleerde

deelmodules.

5 Voorbeelden van types zijn: tekst, integer, datum, nodereferentie,…

28

A. Deelmodules aanwezig in de CCK core

• Content Permissions: Deze module creëert de mogelijkheid om veldpermissies

in te stellen voor de verschillende gecreëerde velden. Dit wil zeggen dat men bij

de toegangsrechten voor gebruikers per veld kan instellen welke

gebruikersgroep dit veld kan bekijken en bewerken. Men kan er bijvoorbeeld

voor kiezen dat bepaalde velden enkel zichtbaar zijn voor administrators maar

niet voor geverifieerde gebruikers.

• Fieldgroup: Deze module maakt het mogelijk om bepaalde velden die werden

aangemaakt te groeperen. Het resultaat is dat in het inhoudstype de

gegroepeerde velden in een kader worden geplaatst met bovenaan de naam

van de groep.

• Option Widgets: Deze module levert selectielijsten (dropdown menu’s), vinkje-

en radiobutton widgets voor zowel tekstvelden als numerieke velden.

• Node Reference: Deze module levert een veldtype voor het refereren van de

ene node naar de andere. Indien men een veld aanmaakt met als type node

referentie kan men één of meerdere inhoudstypes selecteren die men wil

refereren in het node referentie veld. Men kan kiezen uit een aantal widgets die

vergezeld gaan met dit veldtype, bijvoorbeeld een automatisch aanvullend

tekstveld, selectielijst of radio buttons. De waarden die in deze widgets getoond

worden zijn de titels van de nodes van het gerefereerde inhoudstype. Soms is

dit echter niet wenselijk, bijvoorbeeld in het geval dat men liever de waarden

van een bepaald veld van het andere inhoudstype wil tonen in plaats van de

titels. Om dit te bereiken moet men gebruikmaken van een andere module,

namelijk ‘Views’. De module ‘Views’ komt uitgebreid aan bod in het hoofdstuk

over de gegevensbank.

• Number: Deze module levert numerieke veldtypes, namelijk decimaal, float en

integer. De widgets die bij dit veldtype gebruikt kunnen worden zijn selectielijst,

radio button, aan/uit vinkje of een gewoon tekstveld waarbij men het cijfer

manueel kan ingeven.

• Text: Deze module maakt het mogelijk om velden met als type ‘tekst’ aan te

maken. Hierbij kan men kiezen uit de volgende widgets: selectielijst, radio

button, aan/uit vinkje, tekstveld met één rij of een tekstveld met meerdere rijen.

29

B. Deelmodules die niet aanwezig zijn in de CCK core

• Email: Deze module maakt het mogelijk om het type van een veld in te stellen

als e-mail. Dit type levert een tekstveld waarin men een e-mailadres kan

invoeren. Er wordt gecontroleerd of het ingevoerde e-mailadres een geldige

vorm heeft. Indien dit niet zo is wordt er een foutmelding gegenereerd en dient

men het e-mailadres te corrigeren.

• Computed Field: Het veldtype ‘computed’ maakt het mogelijk om een veld in te

voeren die een berekening uitvoert. Dit veld levert waarden die berekend

worden uit een ingevoerde PHP code. Deze PHP code kan gebruik maken van

andere velden, database tabellen, gebruikers,… De mogelijkheden zijn quasi

eindeloos, de bijnaam van dit veldtype is dan ook terecht ‘het Zwitserse zakmes

onder de CCK velden’.

• Serial: Serievelden worden beheerd per inhoudstype en genereren een uniek

sequentieel nummer per node van een bepaald inhoudstype. Er wordt ook voor

gezorgd dat de waarden eveneens uniek zijn bij nodes die op hetzelfde moment

gecreëerd worden.

• Conditional Fields: Als velden of gegroepeerde velden gecontroleerd worden

door de inhoud van andere velden (de controlerende velden) betekent dit dat de

zichtbaarheid van deze gecontroleerde velden afhankelijk is van de waardes

van de andere velden. Dit wil zeggen dat men de toegestane waarden6 van een

veld kan gebruiken om een ander veld te controleren. Het gecontroleerde veld

zal enkel zichtbaar worden als in het controlerende veld een waarde aangeduid

wordt die overeenkomt met de waarde die ingesteld werd. Bijvoorbeeld: Men

kan met een aan/uit vinkje antwoorden op de vraag “Heeft u huisdieren?”. Enkel

indien men het vinkje aanklikt, wat ja betekent, wordt een extra selectielijst met

diersoorten zichtbaar waaruit men het soort huisdier kan selecteren.

6 De toegestane waarden van een veld zijn enerzijds de mogelijke waarden die gespecificeerd werden voor option widgets of anderzijds waarden die manueel ingesteld werden bij een gewoon tekstveld. Een voorbeeld van het eerste geval is de selectielijst. Dit is een eindige lijst van waarden waaruit de gebruiker een keuze kan maken. Een voorbeeld van het tweede geval is dat men bij een tekstveld instelt dat de gebruiker enkel ‘ja’ of ‘nee’ mag invullen.

30

• CCK Required Reference Select: Deze module voegt een ‘Selecteer…’ optie toe

aan elk, verplicht in te vullen, veld van het type node referentie met als option

widget selectielijst. Indien deze module niet gebruikt wordt is de eerste waarde

in een selectielijst één van de mogelijke waarden die kunnen aangeduid

worden. Dit kan gevaarlijk zijn indien de gebruiker even onoplettend is en

vergeet dat hij het verplichte veld eigenlijk niet heeft aangepast. Hierdoor zou

een foutieve waarde kunnen worden opgeslagen. Door ‘Selecteer…’ in te

stellen als default waarde weet men dat men het veld nog niet heeft ingevuld en

krijgt men ook een foutmelding indien men geen andere waarde aanduidt.

• Automatic Nodetitles: Deze module laat toe om het veld titel in het inhoudstype

te verbergen. Indien dit niet gebeurd krijgt de gebruiker een tekstveld te zien

waarin hij een titel dient in te voeren. Omdat het niet wenselijk is dat een node

zonder titel wordt opgeslagen in de database laat deze module toe om een

patroon in te vullen op basis waarvan de titel automatisch zal worden

gecreëerd. Met behulp van de ‘Token’ module (deze module wordt uitgelegd

op p.30) is het mogelijk om data, ingevuld in een veld van het betreffende

inhoudstype, te gebruiken als titel van de node. Het is ook mogelijk om PHP

code te gebruiken voor het genereren van een passende titel voor de node.

4.1.2 Unique Field

Hoewel ‘Unique Field’ integreert met de CCK module kan deze toch niet als deelmodule

van CCK gecategoriseerd worden. Deze module integreert namelijk ook met een aantal

andere modules zoals ‘Date’ en ‘Content Taxonomy’. Met behulp van ‘Unique Field’

kan men instellen of een node titel, auteur, taal of CCK veld uniek moet zijn binnen een

gegeven context. Zo kan er aangeduid worden of de waarden van de CCK velden uniek

moeten zijn in nodes van hetzelfde inhoudstype, in nodes van alle inhoudstypen

(sommige velden komen in verschillende inhoudstypes voor) of in nodes geschreven in

dezelfde taal. Verder kan ingesteld worden of de waarde van elk aangeduid veld uniek

moet zijn of dat de combinatie van de waarden van de geselecteerde velden uniek

moeten zijn. Telkens een nieuwe node aangemaakt wordt of een bestaande node

gewijzigd wordt, worden de waarden van de geselecteerde velden geëvalueerd. Deze

functie is niet hoofdlettergevoelig.

31

4.1.3 Date

De ‘Date’ module omvat verschillende modules die allerhande zaken mogelijk maken in

verband met data en kalenders. In het kader van deze website wordt gebruik gemaakt

van één van de deelmodules die eveneens de naam ‘Date’ heeft. Om ‘Date’ te kunnen

gebruiken dienen twee primaire modules ingeschakeld te zijn, namelijk ‘Date API’ en

‘Date Timezone’. De ‘Date’ module stelt een veldtype datum ter beschikking. Men heeft

hierbij de keuze uit een datum als selectielijst of een tekstveld waarin men een datum

kan invoeren aan de hand van een vooraf ingesteld formaat. Verder heeft men de

mogelijkheid om te kiezen tussen één datum of een begin- en einddatum en allerhande

formaten waarin de data moeten worden ingevoerd of weergegeven.

4.1.4 Token

De ‘Token’ module op zichzelf heeft geen enkele functie, hij dient gebruikt te worden

door andere modules zoals bijvoorbeeld CCK en Views. In de context van onze

inhoudstypes gebruiken we deze module bij het automatisch genereren van titels voor

aangemaakte nodes. We kunnen bij het instellen van deze titel kiezen uit een hele lijst

van gegenereerde tokens. Deze tokens maken het mogelijk om de inhoud van de titel

te genereren op basis van andere informatie. Men kan er bijvoorbeeld voor kiezen om

de waarde van een veld, dat werd ingevuld in een node van een bepaald inhoudstype,

te gebruiken als titel voor de node. Op deze manier kan men bijvoorbeeld bekomen dat

voor het inhoudstype ‘Jongere’ steeds de voornaam van de jongere als de titel van de

node wordt ingesteld. Een aantal andere mogelijkheden zijn het node ID, de datum

waarop de node gecreëerd werd, de auteur van de node,…

4.1.5 Rules

De ‘Rules’ module maakt het mogelijk om Drupal automatisch acties te laten uitvoeren

bij een nader te specificeren gebeurtenis. Er zijn tal van mogelijke combinaties van

acties en gebeurtenissen. Voorbeelden van gebeurtenissen zijn: een gebruiker die

inlogt, inhoud die bekeken wordt, een nieuwe node die wordt opgeslagen,…

Voorbeelden van acties zijn: een e-mail verzenden naar een gebruiker, inhoud

publiceren, een reactie verwijderen. Een mogelijke combinatie is dus bijvoorbeeld:

‘Stuur een bepaalde gebruiker een e-mail nadat hij is ingelogd.’

32

4.2 DE VERSCHILLENDE INHOUDSTYPES

4.2.1 Inhoudstype ‘Voorzieningen’

Dit inhoudstype wordt gebruikt om een nieuwe voorziening toe te voegen aan de

database.

Men is verplicht om de naam van de voorziening, het adres, het e-mailadres en het

telefoonnummer in te vullen.

Optioneel kan men ook aangeven om welk soort voorziening het gaat, wie de

verantwoordelijke is, of de voorziening korting geniet, of er oudere jongeren aanwezig

zijn en of de voorziening verborgen moet worden in het overzicht van de database.

Tenslotte is er nog een tekstveld voorzien waar men, indien gewenst, extra informatie

kan toevoegen over de voorziening.

De naam van de voorziening moet uniek zijn. Indien in de database een voorziening

wordt teruggevonden met dezelfde naam verschijnt er een foutmelding op het scherm.

Naast deze foutmelding verschijnt er ook een link naar de voorziening met dezelfde

naam. Op basis hiervan kan de gebruiker beslissen of het inderdaad om dezelfde

voorziening gaat. Indien het toch om een andere voorziening zou gaan heeft de

gebruiker, ondanks de waarschuwing, de mogelijkheid de voorziening toch op te slaan.

Bizon vzw organiseert in elke provincie een aantal activiteiten. Om de deelnemers

zoveel mogelijk te kunnen spreiden over de verschillende activiteiten, is het belangrijk

dat van elke voorziening de juiste provincie gekend is. Gezien de provinciale spreiding

cruciaal is voor de erkenning als landelijk georganiseerd jeugdwerk, moet vermeden

worden dat gebruikers, al dan niet doelbewust, een verkeerde provincie invullen.

Daarom is het niet mogelijk voor de gebruikers om de provincie zelf in te voeren. De

provincie zal bij het opslaan van de nieuwe voorziening berekend worden op basis van

de postcode. Hiervoor beschikte Bizon vzw reeds over een algoritme, geschreven in

Visual Basic.

Het e-mailadres moet een geldige vorm hebben, indien niet wordt er een foutmelding

gegenereerd.

33

Bij het opslaan van de nieuwe voorziening wordt er automatisch een uniek

klantennummer aangemaakt. Het is dit klantennummer dat een voorziening zal

gebruiken indien hij een aanvraag tot inschrijving wil invoeren. De aanvraag kan enkel

verzonden worden indien de voorziening een correct klantennummer invoert. Gezien

de kans op een correcte gok groot is bij een klantennummer bestaande uit één cijfer,

hebben we er voor geopteerd om klantennummers te genereren van minimaal drie

cijfers.

A. Het klantennummer

Het unieke klantennummer wordt gegenereerd door middel van twee velden,

‘field_berekenklantnummer’ en ‘field_klantennummer’. Het veld berekenklantnummer is

een serieveld en genereert een uniek sequentieel cijfer per aangemaakte node van het

inhoudstype ‘Voorzieningen’. Gezien het niet mogelijk is om de startwaarde in te stellen

begint het serieveld bij één. Uit het bovenstaande bleek dat dit niet wenselijk is.

Daarom werd het veld ‘klantennummer’ aangemaakt, met een ‘computed’ veldtype. Dit

veld telt de waarde 100 op bij het getal, dat gegenereerd werd door het serieveld, aan

de hand van volgende code:

$node_field[0]['value'] = $node->field_berekenklantnummer[0]['value'] + 100;

Gezien het serieveld pas berekend wordt tijdens het opslaan, kan het ‘klantennummer’

de waarde van ‘berekenklantnummer’ niet gebruiken bij de eerste maal dat de node

opgeslagen wordt. Dit is uiteraard niet de bedoeling. Als oplossing werd met behulp

van de ‘Rules’ module een ‘rule’ aangemaakt die, telkens er een node wordt

opgeslagen van het inhoudstype ‘Voorzieningen’, de volgende PHP code uitvoert:

auto_nodetitle_operations_update(array($node->nid));

De code zorgt ervoor dat de node na het opslaan nogmaals geüpdatet wordt, waardoor

de seriewaarde correct gegenereerd wordt en de berekening correct wordt uitgevoerd

en opgeslagen in de database.

Het klantennummer wordt met behulp van de modules ‘Automatic Nodetitles’ en

‘Token’ gebruikt als titel voor de nodes van dit inhoudstype.

34

B. Unieke voorzieningen

Met behulp van de module ‘Unique Field’ wordt ervoor gezorgd dat men dezelfde

voorziening niet meermaals in de database invoert. De module controleert of de

waarde in het veld ‘naam_voorziening’ niet reeds eerder opgenomen werd in de

database. Ook werd gebruikers de mogelijkheid gelaten om, ondanks de

waarschuwing, toch door te gaan met het opslaan van de node.

C. Geldig e-mailadres

De module ‘Email’ gaat na of het ingevoerde e-mailadres een correcte vorm heeft.

D. Groeperen van velden

Met behulp van de CCK deelmodule ‘Fieldgroup’ werden een aantal velden

gegroepeerd. Voor de velden met betrekking tot het adres van de voorziening werd

een groep met als naam ‘adres’ aangemaakt. Voor de velden met betrekking tot de

gegevens van de verantwoordelijke van de voorziening werd een groep met als naam

‘verantwoordelijke’ aangemaakt. Tenslotte werd voor de optionele velden ‘verborgen’,

‘oudere jongeren’, ‘korting’ en ‘extra info’ een groep aangemaakt met als naam ‘extra’.

E. Het berekenen van de provincie

Het veld ‘land’ is het eerste veld van de groep ‘adres’. Dit (verplichte) veld bestaat uit

een selectielijst met een aantal landen.

De waarde ervan staat standaard ingesteld op ‘België’, gezien de meeste

voorzieningen die jongeren inschrijven gevestigd zijn in België. Het veld land

controleert drie andere velden, namelijk ‘field_postcode’, ‘field_provincie’ en

‘field_postcode buitenland’.

Indien de waarde van ‘land’ België is, wordt het verplichte veld ‘postcode’ getoond. In

dit veld moet men een integer die gelijk aan of groter is dan 1000 en kleiner dan of

gelijk aan 9999 invullen. Indien er een andere waarde wordt ingevuld, wordt een

foutmelding gegenereerd.

Indien de waarde van ‘land’ verschillend is van België, wordt het veld

‘postcode_buitenland’ zichtbaar. Dit is een tekstveld, gezien de postcode van sommige

landen wordt voorafgegaan door letters.

35

Het veld ‘provincie’, van het type ‘computed’, berekent op basis van de waarde in het

veld ‘postcode’ de provincie. Het Visual Basic algoritme werd hiervoor omgezet naar de

volgende code:

$postcode = $node->field_postcode[0]['value']; switch ($postcode) { case ($postcode >= 1000 && $postcode < 1300): $node_field[0]['value'] = "Brussel"; break; case ($postcode >= 1300 && $postcode < 1500): $node_field[0]['value'] = "Waals-Brabant"; break; case ($postcode >= 1500 && $postcode < 2000): $node_field[0]['value'] = "Vlaams-Brabant"; break; case ($postcode >= 2000 && $postcode < 3000): $node_field[0]['value'] = "Antwerpen"; break; case ($postcode >= 3000 && $postcode < 3500): $node_field[0]['value'] = "Vlaams-Brabant"; break; case ($postcode >= 3500 && $postcode < 4000): $node_field[0]['value'] = "Limburg"; break; case ($postcode >= 4000 && $postcode < 5000): $node_field[0]['value'] = "Luik"; break; case ($postcode >= 5000 && $postcode < 6000): $node_field[0]['value'] = "Namen"; break; case ($postcode >= 6000 && $postcode < 6700): $node_field[0]['value'] = "Henegouwen"; break; case ($postcode >= 6700 && $postcode < 7000): $node_field[0]['value'] = "Luxemburg"; break; case ($postcode >= 7000 && $postcode < 8000): $node_field[0]['value'] = "Henegouwen"; break; case ($postcode >= 8000 && $postcode < 9000): $node_field[0]['value'] = "West-Vlaanderen"; break; case ($postcode >= 9000 && $postcode < 10000): $node_field[0]['value'] = "Oost-Vlaanderen"; break; }

36

4.2.2 Inhoudstype ‘Jongeren’

Dit inhoudstype wordt gebruikt om een nieuwe jongere aan de database toe te voegen.

Men is verplicht om de voorziening waartoe de jongere behoort aan te duiden.

Dit veld bestaat uit een selectielijst waarin alle voorzieningen, die reeds in de databank

aanwezig zijn, getoond worden. Verder zijn de voornaam en de familienaam verplicht

in te vullen tekstvelden. De geboortedatum dient aangeduid te worden in een

selectieveld en is vereist. Tenslotte is men ook verplicht om het geslacht van de

jongere aan te vinken. Optioneel kan een telefoonnummer van de jongere worden

toegevoegd.

Het is niet wenselijk dat dezelfde jongere meermaals voorkomt in de database. Als

men een jongere toevoegt waarvan de combinatie van voornaam en familienaam reeds

voorkomt in de database, dient er een waarschuwing gegeven te worden. Naast deze

waarschuwing krijgt men ook een link naar de jongere met dezelfde naam. Op basis

hiervan kan de gebruiker beslissen of het inderdaad om dezelfde jongere gaat. Gezien

het steeds mogelijk is dat meerdere jongeren dezelfde voornaam en familienaam

hebben is er, ondanks de waarschuwing, toch de mogelijkheid om de jongere alsnog

op te slaan.

A. Unieke jongeren

Met behulp van de module ‘Unique Field’ wordt ervoor gezorgd dat men dezelfde

jongere niet meermaals in de database invoert. De module controleert of de waarde in

het veld ‘voornaam’ in combinatie met de waarde in het veld ‘familienaam’ niet eerder

opgenomen werd in de database. Ook werd gebruikers de mogelijkheid gelaten om,

ondanks de waarschuwing, toch door te gaan met het opslaan van de node.

B. Selectielijst met voorzieningen uit de database

Er werd een veld ‘content_field_vid’ met als type node referentie aangemaakt en met

als option widget een selectielijst. Indien men bij het te refereren inhoudstype

‘Voorzieningen’ kiest, zijn de waarden die verschijnen in de selectielijst de

klantennummers van de voorzieningen. Gezien we niet de klantennummers willen,

maar de namen van de voorzieningen, werd er een View aangemaakt met de namen

van de voorzieningen. Na het aanmaken kan deze view geselecteerd worden bij de

instellingen van de node referentie.

37

C. Nodetitels van het inhoudstype ‘Jongeren’

De titel van elke node van dit inhoudstype wordt, met behulp van de modules

‘Automatic Nodetitles’ en ‘Token’ , opgebouwd uit de naam van de voorziening waartoe

de jongere behoort (‘field_vid_value’), gevolgd door de familienaam en de voornaam

van de jongere (‘field_familienaam_value’ en ‘field_voornaam_value’). In tokenvorm is

dit:

[field_vid-title-raw] | [field_familienaam-raw] [field_voornaam-raw]

4.2.3 Inhoudstype ‘Activiteit’

Dit inhoudstype wordt gebruikt om een nieuwe activiteit aan de database toe te

voegen.

Bij het aanmaken van een nieuwe activiteit is men verplicht de naam van de activiteit,

de uiterste annulatiedatum, het type activiteit, de datum waarop de activiteit doorgaat

en de locatie van de activiteit in te vullen. Tenslotte zijn er nog twee optionele velden,

namelijk dagprijs en procent medische annulatie.

Afhankelijk van het type activiteit dat werd geselecteerd verschijnt er ofwel een

enkelvoudig datumveld ofwel een meervoudig datumveld waarin men een begin- en

einddatum kan invullen.

Indien men koos voor een kamp of een weekend wordt het meervoudig veld zichtbaar.

De begindatum dient hierbij steeds voor de einddatum te liggen, indien dit niet zo is

wordt er een foutmelding gegenereerd.

Gezien bij een ééndagsactiviteit de begin- en einddatum gelijk zijn aan elkaar, wordt

hierbij slechts één datumveld zichtbaar gemaakt.

A. Datum aan de hand van het type activiteit

Met behulp van de ‘Conditional Fields’ module werden de waarden van het veld

‘type_activiteit’ controlerend gemaakt voor de zichtbaarheid van het enkelvoudige

datumveld (‘field_activiteit_datum_value’) en het meervoudige datumveld

(‘field_begin_einddatum_value’). Indien nog niets werd aangeduid in het selectieveld

‘type_activiteit’ wordt er geen enkel datumveld getoond. Gezien dit een verplicht veld is

dient men een keuze te maken uit de verschillende types activiteiten. Op basis van

deze keuze wordt ofwel het verplichte veld ‘activiteit_datum’ , ofwel het verplichte veld

‘begin_einddatum’ zichtbaar.

38

B. Nodetitels van het inhoudstype ‘Activiteit’

De titel van elke node van dit inhoudstype wordt, met behulp van de modules

‘Automatic Nodetitles’ en ‘Token’ , opgebouwd uit de naam van de activiteit

(‘field_naam_value’), gevolgd door de tekststring ‘met als annulatiedatum’ en tenslotte

de ingevulde annulatiedatum (‘field_annulatiedatum_value’).

In tokenvorm wordt dit:

[field_naam-raw] met annulatiedatum

[field_annulatiedatum-dd]/[field_annulatiedatum-mm]/[field_annulatiedatum-yyyy]

4.2.4 Inhoudstype ‘Inschrijving’

Dit inhoudstype wordt gebruikt om een nieuwe inschrijving aan de database toe te

voegen.

Men is verplicht om het type activiteit, de naam van de activiteit, de naam van de

jongere, de datum van de actie, het type van de actie en de prijs in te vullen. De velden

medisch attest, toestemming buitenland en opmerkingen zijn optioneel.

Afhankelijk van het type activiteit (ééndagsactiviteit, weekend en kamp) dat werd

geselecteerd verschijnt er een veld waarin men de naam en de annulatiedatum van de

activiteit kan aanduiden. Deze selectielijst toont enkel de namen van de activiteiten van

het gespecificeerde type.

Vervolgens selecteert men uit de selectielijst ‘naam jongere’ de in te schrijven jongere.

Deze selectielijst bevat een lijst van alle jongeren die reeds opgenomen zijn in de

database samen met de naam van de voorziening waarin ze verblijven.

A. Naam aan de hand van het type activiteit

Het veld ‘type_activiteit’ werd reeds gebruikt in het inhoudstype ‘Activiteit’. Opnieuw

werden de waarden van dit veld, met behulp van de ‘Conditional Fields’ module,

controlerend gemaakt voor de zichtbaarheid van andere velden. Er werden drie velden

aangemaakt: ‘eendagsactiviteit’ (‘content_field_eendagsactiviteit’), weekend

(‘content_field_weekend’) en ‘kamp’ (‘content_field_kamp’). Deze drie velden hebben

het type node referentie.

39

Indien nog niets werd aangeduid in het selectieveld ‘type_activiteit’ wordt geen enkel

van deze velden weergegeven. Gezien dit een verplicht veld is dient men een keuze te

maken uit de verschillende types activiteiten. Op basis van deze keuze komt de

selectielijst met de namen van de activiteiten van het gespecificeerde type

tevoorschijn.

Om de juiste waarden in deze velden te kunnen weergeven werden er voor elk type

activiteit een View gemaakt met de namen van de activiteiten. Gezien de drie velden

van het type node referentie zijn, is het mogelijk om bij elk veld de juiste View in te

schakelen zodanig dat de juiste namen worden weergegeven.

B. Selectielijst met de jongeren (en hun voorzienin g) uit de database

Er werd een veld ‘field_jid_nid’ met als type node referentie aangemaakt en met als

option widget een selectielijst. Indien men bij het te refereren inhoudstype ‘Jongeren’

kiest, zijn de waarden die verschijnen in de selectielijst van de vorm ‘Klantennummer

voorziening: Naam van de jongere’. Gezien we niet de klantennummers willen, maar

de namen van de voorzieningen, werd er een View aangemaakt met telkens de naam

van de jongere en de voorziening waartoe deze behoort. Na het aanmaken kan deze

view geselecteerd worden bij de instellingen van de node referentie.

4.2.5 Inhoudstype ‘Onkosten’

Dit inhoudstype wordt gebruikt om een nieuwe onkostennota aan de database toe te

voegen.

Men is verplicht om de gegevens van de jongere en de prijs aan te duiden. Optioneel

kan men in het tekstveld met het label ‘beschrijving’ invullen van waar de extra kosten

afkomstig zijn.

A. Selectielijst met de jongeren uit de database

Er werd een veld ‘field_iid_nid’ aangemaakt met als type node referentie. De waarden

die in de selectielijst van dit veld getoond worden zijn alle jongeren, die ingeschreven

zijn voor een bepaalde activiteit, gevolgd door de voorziening waartoe ze behoren. Ook

voor deze node referentie werd een View aangemaakt.

40

4.2.6 Inhoudstype ‘Transport’

Dit inhoudstype wordt gebruikt om nieuwe transportinformatie aan de database toe te

voegen.

Men dient verplicht het type van de activiteit, de naam van de activiteit, de naam van

de voorziening, het vervoer van en naar de activiteit en de begeleider op de heen- en

terugreis in te vullen. Optioneel kan men in het tekstveld met het label ‘Opmerkingen’

nog extra informatie toevoegen.

Afhankelijk van het type activiteit (ééndagsactiviteit, weekend en kamp) dat werd

geselecteerd verschijnt er een veld waarin men de naam en de annulatiedatum van de

activiteit kan aanduiden. Deze selectielijst toont enkel de namen van de activiteiten van

het gespecificeerde type.

De naam van de voorziening wordt gekozen uit een selectielijst waarin alle

voorzieningen, die reeds in de databank aanwezig zijn, getoond worden.

A. Naam aan de hand van het type activiteit

Dit werd op dezelfde manier en met dezelfde velden geïmplementeerd als bij het

inhoudstype ‘Activiteit’ (p. 38).

B. Selectielijst met voorzieningen uit de database

Dit werd op dezelfde manier en met hetzelfde veld geïmplementeerd als bij het

inhoudstype ‘Jongeren’ (p. 35).

C. Groeperen van velden

Met behulp van de CCK deelmodule ‘Fieldgroup’ werden een aantal velden

gegroepeerd. Er werd een groep ‘Heen’ en een groep ‘Terug’ aangemaakt. De groep

‘Heen’ bevat de velden ‘field_vervoer_heen’ en ‘field_begeleider_heen’. De groep

‘Terug’ bevat de velden ‘field_vervoer_terug’ en ‘field_begeleider_terug’.

41

4.2.7 Inhoudstype ‘Aanvraag’

Dit inhoudstype kan door voorzieningen worden gebruikt om een aanvraag tot

inschrijving voor een bepaalde activiteit in te dienen.

Enkel voorzieningen die reeds geregistreerd zijn bij Bizon vzw kunnen een aanvraag

tot inschrijving indienen. Bij het toevoegen van een voorziening aan de database wordt

er een klantennummer gegenereerd. De voorzieningen die geregistreerd zijn bij Bizon

kennen hun eigen klantennummer.

In het eerste verplichte veld, dienen de voorzieningen dit klantennummer in te vullen.

Indien dit klantennummer niet gekend is bij Bizon wordt er een foutmelding

gegenereerd en kan de voorziening geen aanvraag indienen.

De naam van de voorziening en het type en de naam van de activiteit, waarvoor men

een jongere wil inschrijven, zijn verplichte velden. Verder is het ook nodig dat er een

aantal gegevens over de jongere die men wil inschrijven toegevoegd worden, namelijk

de voornaam, de familienaam, de geboortedatum en het geslacht van de jongere.

Optioneel kan men ook het telefoonnummer van de jongere toevoegen.

A. Nagaan of klantennummer correct is

Hiervoor gebruiken we het reeds bestaande veld ‘field_vid’. Dit is een veld van het type

node referentie. Het is mogelijk om per inhoudstype de widget van een bepaald veld te

veranderen zonder dat dit invloed heeft op zijn verschijningsvorm in een ander

inhoudstype. Tot nu toe hebben we voor ‘field-vid’ steeds een selectielijst gekozen als

widget. In dit geval kiezen we echter voor een tekstveld. Hierdoor zijn de toegelaten

waarden voor dit tekstveld gelijk aan de klantennummers die worden aangemaakt in

het inhoudstype ‘Voorzieningen’.

B. Naam aan de hand van het type activiteit

Dit werd op dezelfde manier en met dezelfde velden geïmplementeerd als bij het

inhoudstype ‘Activiteit’ (p. 38).

42

C. Extra informatie over de gebruikte velden

Uitgezonderd het veld ‘field_voorziening_value’, zijn alle velden die in dit inhoudstype

worden gebruikt reeds bestaande velden. Dit heeft als voordeel dat, indien een

aanvraag door een geverifieerde gebruiker of administrator aanvaard wordt, de

informatie over de inschrijving rechtstreeks op de juiste plaats terechtkomt in de

database. Een aanvraag die aanvaard werd, wordt dus omgezet naar een inschrijving.

Gezien in het inhoudstype ‘Inschrijving’ nog andere velden bestaan, werd er voor

gezorgd dat deze extra velden ook opgenomen werden in het inhoudstype ‘Aanvraag’.

Deze worden evenwel niet getoond in het officiële formulier om een aanvraag in te

vullen. Deze verborgen velden krijgen een standaardwaarde mee. Dit zorgt ervoor dat,

wanneer een aanvraag geaccepteerd wordt als een inschrijving, alle benodigde velden

aanwezig zijn zodanig dat de medewerkers van Bizon, indien gewenst, verdere

informatie kunnen toevoegen en aanpassen.

Indien een jongere nog niet aanwezig was in de database, kan er uit dit inhoudstype

voldoende informatie worden gehaald om de jongere automatisch toe te voegen aan

de gegevensbank ‘Jongeren’.

4.2.8 Inhoudstype ‘Algemene Gegevens’

Dit inhoudstype werd gebruikt om de algemene gegevens van Bizon vzw toe te voegen

aan de website. Geen van de gebruikers krijgt de toegang om algemene gegevens toe

te voegen of te verwijderen. Wanneer dit wel het geval zou zijn kan dit enkel tot

redundantie en inconsistenties leiden. Gebruikers met de rol van administrator kunnen

deze gegevens, indien nodig, wel aanpassen.

De ingevoerde informatie bestaat uit het adres, het telefoonnummer en de

bankgegevens (rekeningnummer, IBAN en BIC) van Bizon VZW enerzijds en de naam

van de verantwoordelijke anderzijds.

.

43

5. De gegevensbank

In de primaire links is er een drop-down menu gegevensbank. Dit menu is enkel

zichtbaar voor geverifieerde gebruikers en administrators. Door het betreffende

inhoudstype aan te klikken krijgt de gebruiker vervolgens een pagina te zien met een

overzicht van alle nodes die aangemaakt werden voor dit inhoudstype.

We maken gebruik van overzichten per inhoudstype om gebruikers een beeld te geven

van de data die opgeslagen werd in de databank voor een specifiek inhoudstype. Bij de

overzichten worden steeds bepaalde filters zichtbaar gemaakt waardoor gebruikers

snel een bepaalde node kunnen terugvinden.

In dit deel bespreken we de gegevensbank in detail. Eerst bespreken we de modules

die werden gebruikt om de gegevensbank te creëren. Vervolgens bespreken we per

inhoudstype hoe het overzicht gegenereerd werd, welke mogelijke filters zichtbaar zijn

voor de gebruikers en welke operaties toegelaten zijn op de nodes.

5.1 MODULES

5.1.1 Views

De overzichten worden gegenereerd door gebruik te maken van de module ‘Views’.

Zoals beschreven in De Tré (2007) worden de views op de database in de externe laag

van de drie-lagen-architectuur van het databasemodel gedefinieerd. Hierdoor kan men

een gepersonaliseerde kijk op de database realiseren.

De module ‘Views’ werd speciaal ontwikkeld om de CCK velden van een bepaald

inhoudstype op een gestructureerde manier weer te geven. Elke view kan op een

andere manier weergegeven worden aan de hand van displays. Men kan een view

weergeven als een pagina, een blok, een bijlage of een feed. Voor de gegevensbank

hebben we een view ‘databank’ aangemaakt, met voor elk inhoudstype een ander

pagina-display. Elke sub-view van de view ‘databank’ wordt aldus weergegeven als

een pagina met een eigen URL en een eigen menu.

De overzichten fungeren verder als een interface om de opgeslagen nodes te

bewerken, te verwijderen of in detail te bekijken. Een overzicht geeft immers maar een

deel van de velden van een bepaald inhoudstype weer. Door een detail van een node

aan te vragen kan men de waarde voor alle velden van dat inhoudstype bekijken.

44

5.1.2 Views Bulk Operations

Het is wenselijk dat men de nodes in een view ook kan bewerken, verwijderen of,

wanneer het om een aanvraag gaat, aanvaarden. Hiervoor hebben we gebruik

gemaakt van de module ‘Views Bulk Operations’. Deze module combineert views met

bepaalde acties en laat verschillende operaties op de weergegeven nodes toe.

5.2 ACTIVITEITEN

5.2.1 Overzicht

Om aan te duiden welke inhoud we in de view activiteiten te zien willen krijgen dienen

we de filters in te stellen. Een node van het inhoudstype activiteit wordt standaard

gepubliceerd. In de ‘filter’ dient dus aangeduid te worden dat het om een node gaat van

het type activiteit (Node: type=activiteit) en dat deze node gepubliceerd moet zijn

(Node: Gepubliceerd Ja).

Bij het onderdeel ‘fields’ kunnen we instellen welke velden er in de tabel moeten

getoond worden. Voor de activiteiten is dit dus de naam van de activiteit, de

annulatiedatum, het type activiteit, de begin - en einddatum van de activiteit, de locatie,

de dagprijs en het percentage medische annulatie.

5.2.2 Filters ter beschikking van de gebruiker

We willen gebruikers toelaten om enkel activiteiten van een bepaald type weer te

geven. Hiervoor maken we een extra filter aan met als inhoud de types activiteiten, die

we zichtbaar maken voor gebruikers in een blok boven de tabel.

5.2.3 Detail, bewerken en verwijderen

Het moet mogelijk zijn voor de gebruikers om nodes in detail te kunnen bekijken en te

bewerken. Dit kan door bij het onderdeel ‘velden’ ook een ‘edit’ link toe te voegen

(Node: edit link) en een link naar de node (Node: Link). Figuur 8 toont een detail van

een activiteit en welke velden bewerkt kunnen worden.

45

Figuur 8: Detail en bewerken van een activiteit.

Vervolgens willen we de gebruikers ook toelaten om een of meerdere activiteiten te

verwijderen uit de database. Dit kan door een bulk operation toe te voegen, namelijk

deze om een node te verwijderen (views_bulk_operations_ delete_node_action).

De gegevens in dit overzicht worden standaard gesorteerd volgens de naam van de

activiteit. Men kan indien gewenst ook sorteren volgens een ander veld door het

kolomhoofd van dit betreffende veld aan te klikken. De URL voor dit overzicht is

/databank/ activiteiten.

5.3 AANVRAGEN

5.3.1 Overzicht

Nodes van het inhoudstype ‘aanvraag’ worden standaard niet gepubliceerd. Indien de

medewerkers van Bizon de aanvraag goedkeuren wordt deze aanvraag gepubliceerd

en komen die gegevens terecht in het overzicht van de inschrijvingen.

Om een overzicht van de aanvragen te genereren moeten we de filter dus zo instellen

dat enkel nodes weergegeven worden van het type aanvraag die niet gepubliceerd zijn

(Node: Gepubliceerd Nee ; Node: Type = aanvraag).

De velden die we in het overzicht willen weergeven zijn de datum van de aanvraag, de

voorziening die werd opgegeven, de naam van de jongere, de activiteit waarvoor een

aanvraag werd ingediend, het telefoonnummer, het geslacht en de geboortedatum van

de jongere.

We bouwen echter nog een extra controle in. Een voorziening die een aanvraag wenst

in te dienen moet over een geldig klantennummer van Bizon beschikken. Het is echter

mogelijk dat een voorziening een geldig klantennummer opgeeft, maar als naam van

46

de voorziening een naam opgeeft die niet bij dat geldige klantennummer hoort. Door

een kolom ‘werkelijke voorziening’ bij te voegen kan een medewerker beslissen om bij

verschillen tussen de ingeschreven voorziening en de werkelijke voorziening de

aanvraag te weigeren.

Het veld ‘werkelijke voorziening’ kan in een view weergegeven worden door een relatie

toe te voegen. In dit geval moet er een relatie zijn met het inhoudstype ‘Voorzieningen’.

Deze relatie kan aangemaakt worden door een nieuwe relatie toe te voegen namelijk

‘field_vid’. Aan de hand van het klantennummer, ingevuld bij de aanvraag, wordt de

naam van de voorziening uit het inhoudstype voorzieningen gehaald ((voorziening)

Inhoud: field_naam_voorziening_value).

De aanvragen worden in het overzicht standaard gesorteerd volgens de datum van de

aanvraag. Men kan echter ook volgens een ander veld sorteren door het betreffende

kolomhoofd aan te klikken. De URL voor dit overzicht is /databank/aanvragen.

In Figuur 9 wordt een webpagina van het overzicht van de aanvragen weergegeven.

47

Figuur 9: Overzicht aanvragen.

48


We willen de medewerkers toelaten om de inhoud die weergegeven wordt in de view

zelf, te filteren. Zo kan men door een filter die bovenaan de view verschijnt enkel de

aanvragen voor een bepaalde activiteit weergeven, of enkel de aanvragen van een

bepaalde voorziening weergeven.


Om het mogelijk te maken voor de gebruikers om nodes in detail te bekijken en te

bewerken, voegen we in het onderdeel ‘velden’ van de view ook een ‘edit’ link toe

(Node: edit link) en een link naar de node (Node: Link).

Aangezien de medewerkers hier een overzicht van de aanvragen te zien krijgen,

dienen zij de mogelijkheid te hebben om deze aanvragen te aanvaarden of te

verwijderen. We voegen dus de bulk operatie ‘verwijderen’ toe alsook de operatie

‘publiceren’. Door een aanvraag te aanvaarden, publiceert men in feite de aanvraag.

De aanvraag verdwijnt hierdoor uit het overzicht van de aanvragen, aangezien we in de

filter ingesteld hebben dat we enkel de aanvragen die niet gepubliceerd zijn willen te

zien krijgen.

5.4 INSCHRIJVINGEN

5.4.1 Overzicht

In de view van de inschrijvingen willen we een overzicht krijgen van de aangemaakte

inschrijvingen, maar ook van de gepubliceerde aanvragen. Beide inhoudstypes

gebruiken immers dezelfde velden waardoor een aanvraag ook als een inschrijving kan

beschouwd worden.

Anonieme gebruikers krijgen bij het invullen van een aanvraag echter niet alle velden

te zien waardoor deze lege velden een default waarde krijgen. Wanneer bijvoorbeeld

het veld ‘Actie’ leeg is krijgt dit standaard de waarde ‘inschrijving’. De prijs van een

activiteit dient bij de aanvraag niet ingevuld te worden. Dit veld krijgt dus de waarde

‘0.00’. De datum van de inschrijving krijgt automatisch de datum van de aanvraag. De

velden ‘toestemming buitenland’ en ‘medisch attest’ krijgen automatisch de waarde

‘geen info’, en het veld ‘opmerkingen’ blijft per default leeg.

Een gepubliceerde aanvraag kan dus dankzij deze aanpassingen als een inschrijving

beschouwd worden.

49

Nieuwe inschrijvingen worden standaard gepubliceerd en aanvragen mogen enkel

opgenomen worden in het overzicht van de inschrijvingen wanneer deze gepubliceerd

werden.

We dienen dus in de filter van de view inschrijvingen in te stellen dat we enkel inhoud

willen zien die gepubliceerd is, maar die zowel van het inhoudstype inschrijving of

aanvraag mag zijn (Node: type in aanvraag, inschrijving). Wanneer een medewerker

dus een aanvraag aanvaardt (publiceert) verdwijnt deze aanvraag uit het overzicht van

de aanvragen en komt deze terecht in het overzicht van de inschrijvingen.

In het overzicht van de inschrijvingen willen we als velden de familienaam en de

voornaam van de jongere zien, de naam van de activiteit waarvoor de jongere

ingeschreven is, de datum van de inschrijving, om welke actie het gaat, wat de prijs is,

of de jongere toestemming heeft om naar het buitenland te reizen, of de jongere over

een medisch attest beschikt, en eventuele opmerkingen.


Er werden filters ter beschikking gesteld aan de medewerkers om de view aan te

passen aan hun wensen. Zo hebben we filters zichtbaar gemaakt waardoor men enkel

de inschrijvingen voor een bepaalde activiteit of voor een bepaalde jongere kan

bekijken.

Men heeft ook de mogelijkheid om op basis van ‘actie’ de view aan te passen en

bijvoorbeeld enkel de medische annulaties te bekijken.


Om de inschrijvingen in detail te kunnen bekijken werd een detail-link toegevoegd en

om de inschrijvingen vlot te kunnen bewerken werd een veld met een edit-link

toegevoegd.

Er werd vervolgens nog een bulk operatie toegevoegd waardoor men vlot één of

meerdere inschrijvingen uit de database kan verwijderen. De gegevens in het overzicht

van de inschrijvingen worden standaard gesorteerd volgens de familienaam van de

jongere. Men kan echter ook op andere velden sorteren door het betreffende

kolomhoofd aan te klikken. De URL voor dit overzicht is /databank/inschrijvingen.

50

5.5 JONGEREN

5.5.1 Overzicht

In het overzicht van de jongeren worden alle jongeren weergegeven die toegevoegd

werden door de medewerkers van Bizon. De jongeren die via een aanvraag werden

ingevuld dienen echter ook te worden weergegeven. Nodes van het inhoudstype

jongeren worden standaard gepubliceerd. We willen de jongeren die ingevuld werden

bij de aanvraag ook enkel toevoegen in de tabel jongeren wanneer deze aanvraag

aanvaard werd (e.a. gepubliceerd).

In de filter van deze view dienen we dus aan te geven dat we enkel gepubliceerde

nodes wensen weer te geven (Node: gepubliceerd Ja). Deze nodes mogen echter

zowel van het inhoudstype aanvraag als van het inhoudstype jongeren afkomstig zijn

(Node: type = aanvraag, jongeren).

In deze view willen we onder andere dat het veld met de naam van de voorziening en

het klantennummer zichtbaar is maar dat deze weergegeven worden in een kolom.

Door de output van de naam van de voorziening te herschrijven, met behulp van de

‘Token’ module, kunnen we het klantennummer tussen haakjes weergeven na de

naam van de voorziening ([field_naam_voorziening_value] ([field_vid_nid])).

Verder willen we dat de voornaam en familienaam van de jongere in het overzicht

staat, het telefoonnummer, de geboortedatum en het geslacht van de jongere.

De gegevens in het overzicht van de jongeren worden standaard gesorteerd volgens

de naam van de voorziening. Door een kolomhoofd aan te klikken kan men de

gegevens echter ook sorteren volgens een ander veld. De URL voor dit overzicht is

/databank/jongeren.


Er werd een filter beschikbaar gesteld voor de medewerkers om de jongeren per

voorziening weer te geven.


Om gebruikers in staat te stellen een node in detail te bekijken of te bewerken hebben

we naast de velden van het inhoudstype jongeren ook een edit-link field en een detail-

link field toegevoegd. Tevens werd er een bulk operatie toegevoegd om een of

meerdere jongeren te kunnen verwijderen.

51

5.6 TRANSPORTINFO

5.6.1 Overzicht

Nodes van het inhoudstype transportinfo worden standaard gepubliceerd. In onze view

dienen we de filter dus zo in te stellen dat enkel de nodes die gepubliceerd en van het

inhoudstype ‘transport’ zijn, getoond worden (Node: Gepubliceerd Ja; Node: type =

transport).

Als velden voor deze view willen we de naam van de voorziening met het

klantennummer (cf. overzicht jongeren), de naam van de activiteit, het vervoer voor de

heenreis, het vervoer voor de terugreis, de begeleiders voor de heen-en terugreis en

het veld opmerkingen.

Het overzicht wordt standaard gesorteerd op de naam van de voorziening. Door een

kolomhoofd aan te klikken kan men echter ook sorteren op basis van een ander veld.

De URL voor dit overzicht is /databank/transportinfo


Er werden twee filters zichtbaar gemaakt zodat medewerkers enkel de transportinfo

voor een welbepaalde activiteit kunnen weergeven, of voor een welbepaalde

voorziening.


Ook in deze view zijn er extra velden toegevoegd met een edit-link en een detail-link,

zodat gebruikers de nodes in detail kunnen bekijken en bewerken.

Verder werd een operatie toegevoegd waardoor men snel een of meerdere nodes van

het inhoudstype transport kan verwijderen.

5.7 VOORZIENINGEN

5.7.1 Overzicht

De nodes van het inhoudstype ‘voorzieningen’ worden standaard gepubliceerd. Voor

deze view dienen we dus in de filter in te stellen dat we enkel gepubliceerde nodes van

het inhoudstype voorzieningen willen zien. De voorzieningen waarbij het veld

‘verborgen’ aangekruist werd mogen echter niet getoond worden in het overzicht. We

dienen dus nog een extra filter toe te voegen namelijk Inhoud: Verborgen = niet

verborgen.

52

De velden die we zichtbaar maken zijn de naam van de voorziening, het

klantennummer, de verantwoordelijke van de voorziening, de velden met de

adresgegevens, het telefoonnummer en het e-mail adres.

Het overzicht van de voorzieningen wordt standaard gesorteerd op de naam van de

voorziening. Het is echter mogelijk om de nodes op een andere manier te sorteren.

Dit kan eenvoudig door op een kolomhoofd in het overzicht te klikken. De nodes

worden op die manier alfabetisch of numeriek gesorteerd op de waardes van dit

betreffende veld. De URL voor dit overzicht is /databank/voorzieningen.


Gebruikers hebben de mogelijkheid om ook de verborgen voorzieningen weer te geven

door in een filter ‘verborgen’ aan te klikken. Hierdoor kan men de voorzienings-node

aanpassen en deze eventueel op niet verborgen instellen.

Verder kunnen medewerkers snel de gegevens van een enkele voorziening zichtbaar

maken door een andere publieke filter die toelaat te filteren op de naam van de

voorziening.


Om de nodes in detail te kunnen bekijken en te bewerken werd er in de view bij de

velden een detail-link en een edit-link toegevoegd.

Er werd ook een verwijder-knop voorzien zodat een of meerdere voorzieningen tegelijk

verwijderd kunnen worden.

5.8 ONKOSTEN

5.8.1 Overzicht

De nodes van het inhoudstype onkosten worden standaard gepubliceerd.

In dit overzicht willen we dus gepubliceerde nodes van het inhoudstype onkosten

tonen. Dit duiden we aan in de filter van de onkosten-view.

Bij de velden voegen we de naam van de jongere en het klantennummer van de

voorziening waartoe de jongere behoort toe, de prijs die betaald moet worden en de

beschrijving van de gemaakte onkosten.

Het overzicht van de onkosten wordt standaard gesorteerd op klantennummer en

vervolgens op familienaam. De URL voor dit overzicht is /databank/onkosten.

53


Bij het aanmaken van de view werd in het onderdeel ‘velden’ ook een detail-link en een

link om de node te bewerken toegevoegd.

Verder is het ook mogelijk om een of meerdere nodes te verwijderen dankzij de

toegevoegde operatie ‘verwijderen’.

54

6. Inhoud toevoegen, verwijderen of wijzigen

6.1 INHOUD TOEVOEGEN

Door via het menu ‘Gegevensbank’ het betreffende inhoudstype aan te wijzen,

verschijnt rechts van dit inhoudstype een nieuwe link die de gebruiker naar de pagina

brengt om een nieuwe node van dit inhoudstype toe te voegen.

Wanneer men vervolgens een node van een bepaald inhoudstype wensen toe te

voegen krijgt men te maken met optionele - en verplichte velden. Bepaalde velden zijn

verplicht in te vullen omdat deze velden de node een betekenis geven. Wanneer een

activiteit zou worden toegevoegd zonder hiervoor een naam in te geven heeft de node

geen betekenis meer en valt deze moeilijk te onderscheiden van andere nodes.

Bepaalde velden dienen dus verplicht ingevuld te worden omdat ze essentiële

informatie voor dat bepaald inhoudstype bevatten. Wanneer een gebruiker een

verplicht veld niet ingevuld heeft, verschijnt er een foutmelding dat het verplichte veld

wel degelijk verplicht in te vullen is. Verder wordt redundantie zoveel mogelijk

vermeden door na te gaan of de ingevoerde informatie reeds aanwezig is in de

database. Redundante data vormen immers een potentiële bron van inconsistentie (De

Tré, 2007, p.104).

Om redundante data zoveel mogelijk te voorkomen hebben we gebruik gemaakt van

de module ‘Unique Field’. Deze module laat toe om per inhoudstype de velden (of de

combinatie van velden) aan te duiden die uniek moeten zijn.

6.1.1 Activiteiten toevoegen

Wanneer men een nieuwe activiteit wenst aan te maken dient men een aantal

verplichte velden in te vullen. In dit geval is elk veld verplicht, met uitzondering van de

prijs en het percentage medische annulatie. Het gekozen type activiteit bepaalt of er

een enkele datum dient ingevuld te worden of als er een begin – en een einddatum

dient ingevuld te worden. Voor elk verplicht veld dat niet ingevuld werd verschijnt er

een foutmelding met de verwijzing naar het veld dat nog ingevuld dient te worden.

Indien men een activiteit wenst toe te voegen met een naam die reeds toegevoegd

werd in de database verschijnt er een foutmelding met een link naar de betreffende

node. Wanneer men echter een activiteit wenst toe te voegen met dezelfde naam,

maar van een ander type of die plaatsvindt op een andere datum kan men deze

foutmelding negeren en toch verder gaan met het toevoegen van de nieuwe activiteit.

55

6.1.2 Aanvragen toevoegen

Zoals reeds vermeld hebben enkel anonieme gebruikers de mogelijkheid om een

aanvraag in te dienen. Deze anonieme gebruikers zijn de voorzieningen die een

jongere wensen in te schrijven voor een activiteit. Alvorens dit mogelijk is dienen zij

echter over een geldig klantennummer te beschikken.

Het eerste veld op het aanvraagformulier controleert of het klantennummer gekend is

in de database. Dit is een verplicht veld, waardoor de aanvraag niet opgeslagen wordt

in de database wanneer dit veld blanco wordt gelaten of wanneer er geen geldig

klantennummer ingevoerd werd.

Verder wordt gecontroleerd of alle verplichte velden ingevuld werden. Indien dit niet het

geval is worden de voorzieningen hierop gewezen door middel van een foutmelding.

6.1.3 Inschrijvingen toevoegen

Wanneer men een nieuwe inschrijving wenst toe te voegen dient men alle verplichte

velden in te vullen. Ook hier verschijnt een gepaste foutmelding wanneer dit niet het

geval is. Verder kan men pas nadat men gekozen heeft voor een bepaald type activiteit

de namen van de activiteiten zien. Wij hebben deze optie ingevoerd om de kans op

fouten te verkleinen. Zo is het bijvoorbeeld mogelijk dat er zowel een kamp als een

weekend bestaat met de naam ‘wigwam’. Hierdoor zou een medewerker per abuis de

verkeerde activiteit kunnen aanduiden bij een inschrijving. Deze optie vergroot

daarenboven de gebruiksvriendelijkheid, aangezien er hierdoor geen grote lijst met

activiteiten getoond wordt. Enkel de activiteiten van het type waarvoor men een

jongere wenst in te schrijven zijn zichtbaar.

6.1.4 Jongeren toevoegen

Wanneer men een nieuwe jongere wil toevoegen dient men de voorziening waartoe de

jongere behoort aan te duiden. Dit is belangrijk omdat alle communicatie met

betrekking tot die jongere hoofdzakelijk gebeurt met de betreffende voorziening. Deze

communicatie betreft bijvoorbeeld het transport van en naar een activiteit, maar

bijvoorbeeld ook de betalingen.

Andere belangrijke, en dus ook verplichte velden, zijn de voornaam en de familienaam

van de jongere, de geboortedatum en het geslacht. Het telefoonnummer is niet

verplicht. Ook hier worden foutmeldingen weergegeven per verplicht veld dat niet

ingevuld werd. In Figuur 10 is te zien hoe het formulier om een jongere toe te voegen

eruit ziet.

56

Figuur 10: Jongere toevoegen

Wanneer men een jongere wenst toe te voegen die reeds bestaat in de database wordt

men hier van op de hoogte gebracht. Indien dit toevallig om een jongere gaat met

dezelfde voor- en familienaam als de jongere in de database kan men ervoor kiezen de

nieuwe jongere toch toe te voegen en de foutmelding te negeren.

6.1.5 Transportinfo toevoegen

Wanneer men transportinfo wenst toe te voegen kan men op basis van het type

activiteit, de naam van de activiteit aanduiden waaraan men de transportinfo wenst te

koppelen. Vervolgens dient men de voorziening aan te duiden waarvoor men de

transportinfo toevoegt, en hoe de jongere van en naar de activiteit zal gaan.

Verder heeft men de mogelijkheid om opmerkingen toe te voegen. De controle of

verplichte velden ingevuld werden, wordt ook hier uitgevoerd.

6.1.6 Voorzieningen toevoegen

Wanneer men een nieuw voorziening wenst toe te voegen zijn er verschillende

verplichte velden. Zo is de naam van de voorziening verplicht in te vullen, het adres

(vier velden), het telefoonnummer en het email adres van de verantwoordelijke.

Wanneer deze velden niet ingevuld worden verschijnt er een waarschuwing die hen

laat weten welke velden nog ingevuld dienen te worden. Wanneer men het optionele

veld ‘verborgen’ aankruist, zal de voorziening niet zichtbaar zijn in het overzicht van de

voorzieningen. Deze vraag kwam vanuit de organisatie van Bizon vzw.

Door deze optie wordt het mogelijk om voorzieningen die tijdelijk geen jongeren zullen

inschrijven te verbergen. Wanneer een voorziening later toch opnieuw jongeren wenst

57

in te schrijven kan men deze optie opnieuw uitvinken waardoor de voorziening terug

zichtbaar wordt in het overzicht. We kiezen er ook voor om deze voorziening louter te

verbergen en niet te verwijderen omdat de inschrijvingen van jongeren behorende tot

die voorziening in de database moeten blijven.

Verder wordt er bij het toevoegen van een nieuwe voorziening gecontroleerd of deze

voorziening reeds opgenomen werd in de database. Wanneer dit het geval is wordt

deze specifieke node getoond in de foutmelding.

Indien er echter nog een voorziening is met die naam kan men deze foutmelding

negeren en verder gaan met het toevoegen van deze nieuwe voorziening.

6.1.7 Onkosten toevoegen

Wanneer medewerkers nieuwe onkosten willen toevoegen krijgt men een formulier te

zien met twee verplichte velden. In het eerste veld ‘gegevens jongere’, wordt de naam

van de jongere waarvoor nog onkosten dienen betaald te worden opgegeven. Dit veld

is gekoppeld aan de view noderefiid.

Hierdoor wordt het mogelijk om enkel jongeren en hun voorziening weer te geven die

reeds ingeschreven zijn voor een activiteit. Het volgende veld is ook verplicht, namelijk

het bedrag. Indien de verplichte velden niet ingevuld worden krijgt de gebruiker een

foutmelding te zien. Verder hebben we gebruikers de ruimte gegeven een beschrijving

van de onkosten in te geven.

6.2 INHOUD VERWIJDEREN

In het beste geval bevat een database enkel de informatie die strikt noodzakelijk is.

Hier bestaat natuurlijk geen sluitende controle voor. De mogelijkheid om overbodige

data te kunnen verwijderen is echter van groot belang. Daarom werd er bij de

overzichten de mogelijkheid gegeven om een of meerdere nodes aan te kruisen en

vervolgens te verwijderen. Om gebruikers te behoeden voor fouten wordt een controle

ingebouwd en dient de gebruiker te bevestigen dat hij of zij wel degelijk de

geselecteerde informatie wil verwijderen.

Geen van de medewerkers krijgt echter de mogelijkheid om de algemene gegevens

van Bizon te verwijderen. Het is belangrijk dat men te allen tijde het rekeningnummer of

de verantwoordelijke van Bizon kan nakijken.

58

6.3 INHOUD WIJZIGEN

De gegevensbank van Bizon bevat heel wat data die kan veranderen doorheen de tijd.

Zo kan het bijvoorbeeld zijn dat een jongere niet langer bij voorziening x hoort maar bij

voorziening y. De medewerkers kunnen data wijzigen door naar het overzicht te gaan

van een bepaald inhoudstype en vervolgens naast de te wijzigen node op de knop

‘bewerken’ te klikken. Hierdoor krijgt men alle opgeslagen informatie te zien voor die

node en kan men de nodige wijzigingen aanbrengen. Wanneer men alle te wijzigen

velden aangepast heeft kan men op de knop ‘opslaan’ klikken en werd de data

succesvol gewijzigd.

59

7. Gebruikers

Er werden drie soorten gebruikers gedefinieerd, namelijk anonieme gebruikers,

geverifieerde gebruikers en administrators.

De gebruikers van onze website bestaan in principe uit de medewerkers van Bizon vzw

(geverifieerde gebruikers en administrators) enerzijds en de voorzieningen (anonieme

gebruikers) die een aanvraag tot inschrijving wensen in te dienen anderzijds. In

voorgaande hoofdstukken werd reeds uitgelegd wat de verschillen zijn tussen deze

groepen gebruikers met betrekking tot de toegang tot de data.

Zoals beschreven in De Tré (2007) is enige vorm van toegangscontrole belangrijk om

de authenticiteit van de gebruiker te kunnen controleren. De Bizon medewerkers

beschikken over een gebruikersnaam en een paswoord die opgeslagen werd in de

database.

Er dient echter ook een toegangscontrole te worden ingebouwd die de toevallige

gebruiker onderscheidt van de voorziening die een aanvraag wenst in te dienen. Dit

werd gerealiseerd door in het formulier voor het toevoegen van een aanvraag, een veld

klantennummer toe te voegen. Een werkelijke voorziening krijgt immers een

klantennummer toegewezen wanneer deze wenst samen te werken met Bizon.

Wanneer een gebruiker een geldig klantennummer ingeeft wordt de authenticatie als

geldig beschouwd. Hoewel deze vorm van toegangscontrole niet als veilig beschouwd

kan worden volstaat dit voor het doel van deze website.

Het is namelijk belangrijk dat voorzieningen op een vlotte en gebruiksvriendelijke

manier een aanvraag kunnen indienen, zonder dat ze daarvoor een wachtwoord en

een gebruikersnaam moeten onthouden.

Verder blijven de gegevens in ieder geval afgeschermd van het grote publiek,

aangezien geen van de anonieme gebruikers toegang heeft tot de gegevens. Verder

werden er, zoals beschreven in het hoofdstuk views, extra controles voorzien voor de

medewerkers opdat zij zelf zouden kunnen oordelen over de betrouwbaarheid van de

aanvraag.

Elke geregistreerde gebruiker (geverifieerde gebruikers en administrators) heeft via zijn

account menu de mogelijkheid om zijn persoonlijke gegevens aan te passen.

Het zijn echter enkel de administrators die ook de gegevens van andere gebruikers

kunnen beheren. Het zijn dan ook enkel de gebruikers met de rol van administrator die

60

de primaire link ‘Gebruikers’ te zien krijgen. Via dit menu kan een administrator een

gebruiker toevoegen, verwijderen, de gegevens wijzigen, of een andere rol geven.

Om misbruik tegen te gaan hebben administrators echter niet de mogelijkheid om

wachtwoorden van andere gebruikers te wijzigen. Een wachtwoord van een gebruiker

kan dus enkel gewijzigd worden door de gebruiker zelf, en dit geldt voor alle

gebruikersrollen.

Wanneer een administrator naar het menu ‘Gebruikers’ gaat, komt hij terecht op de

gebruikersbeheer pagina. Deze pagina is onderverdeeld in twee tabbladen. Het eerste

tabblad toont de lijst met alle geregistreerde gebruikers. Dit tabblad laat toe de

gegevens van een gebruiker te wijzigen, een gebruiker te verwijderen, te blokkeren, of

een andere rol te geven. Via het tweede tabblad kan een administrator een gebruiker

toevoegen.

In wat volgt bespreken we eerst de modules die gebruikt werden om de functionaliteit

met betrekking tot te gebruikers te realiseren. Vervolgens zullen we beide tabbladen

uitgebreid bespreken.

7.1 MODULES

7.1.1 Role Delegation

Deze module laat toe om bepaalde rollen, een rol te laten toekennen aan een andere

gebruiker zonder dat zij daarvoor toegang moeten krijgen tot het volledige

beheerpaneel.

Voor deze website werd het voor gebruikers met de rol administrator mogelijk gemaakt

om andere gebruikers de rol van administrator toe te wijzen en af te nemen.

7.1.2 Administer Users by Role

Deze module creëert de mogelijkheid om gebruikers, met een bepaalde rol, nieuwe

gebruikers te laten aanmaken en bestaande gebruikers te bewerken of te verwijderen

zonder dat zij daarvoor toegang moeten krijgen tot het gehele beheerpaneel.

7.1.3 Password Change Confirm

Deze module zorgt ervoor dat indien een gebruiker zijn paswoord wil veranderen, hij

steeds nog eens zijn oude paswoord moet invullen alvorens het gewijzigde paswoord

zal worden opgeslagen. Analoog zal de gebruiker bij het veranderen van andere

61

persoonlijke gegevens eerst zijn paswoord moeten invullen alvorens de wijzigingen

worden opgeslagen. Tevens zorgt de module ervoor dat een administrator bij het

wijzigen van de gegevens van een andere gebruiker, het eigen paswoord moet

invoeren alvorens de wijzigingen worden opgeslagen.

Op deze manier kan worden vermeden dat onbevoegden allerlei instellingen

veranderen indien een computer met een ingelogde gebruiker onbemand wordt

achtergelaten.

7.1.4 Generate Password (Genpass)

De standaard pagina, in Drupal, om een nieuwe gebruiker te voegen bevat een veld

paswoord dat moet worden ingevuld door de administrator. Voor onze website is het

echter niet wenselijk dat de administrator over de mogelijkheid beschikt om een

paswoord te kiezen voor de nieuwe gebruiker. Verder bevat deze pagina een checkbox

waarin men kan aanduiden of de nieuwe gebruiker al dan niet via e-mail op de hoogte

gebracht moet worden van zijn nieuwe account en inloggegevens. Voor onze website

is het echter de bedoeling dat deze e-mail altijd verstuurd wordt. Het is niet de

bedoeling dat de administrator hierover kan beslissen.

Deze module helpt ons een stapje in de goede richting. Hij zorgt er namelijk voor dat

het paswoordveld op deze pagina niet langer verplicht dient te worden ingevuld door

de administrator. Indien de administrator de velden blanco laat, zal er automatisch een

sterk paswoord worden gegenereerd. Indien de administrator de checkbox, voor het

verzenden van een e-mail, vergeet aan te vinken ontstaat er een groot probleem:

zowel de administrator als de nieuwe gebruiker zullen het paswoord nooit kennen en

de nieuwe account is aldus onbruikbaar.

Deze situatie is dus allesbehalve wenselijk voor onze website, daarom hebben wij zelf

de code voor een klein deel herschreven. Ten eerste hebben wij ervoor gezorgd dat

het paswoordveld onzichtbaar wordt, zodanig dat het altijd blanco gelaten wordt en er

dus automatisch een sterk paswoord wordt gegenereerd. Vervolgens hebben we

ervoor gezorgd dat de checkbox voor het verzenden van een e-mail standaard

aangevinkt staat. Tenslotte hebben we ervoor gekozen om deze checkbox ook

onzichtbaar te maken, zodanig dat ook deze instelling niet meer kan veranderd worden

door de administrator.

62

Originele code:

// De administrator maakt een gebruiker aan

if ($_GET['q'] == 'admin/user/user/create') {

// Verander het verplichte paswoordveld naar optioneel

$mode = GENPASS_OPTIONAL;

// Geef een extra waarschuwing bij de checkbox

$notify_item =& _genpass_get_form_item($form, 'notify');

$notify_item['#description'] = t(‘Wanneer het paswoord automatisch gegenereerd

wordt is het aan te raden deze checkbox aan te vinken. Anders zal niemand het

paswoord kennen');

}

Aangepaste code:

// De administrator maakt een gebruiker aan

if ($_GET['q'] == 'admin/user/user/create') {

// Verander het verplichte paswoordveld naar optioneel en verborgen

$mode = GENPASS_RESTRICTED;

// Zorg ervoor dat de checkbox standaard aangevinkt is en verberg deze

$notify_item =& _genpass_get_form_item($form, 'notify');

$notify_item['#value'] = 1;

$notify_item['#access'] = FALSE;

$notify_item['#description'] = t(‘Wanneer het paswoord automatisch

gegenereerd wordt is het aan te raden deze checkbox aan te vinken. Anders zal

niemand het paswoord kennen');

}

7.1.5 Password Strength

Met behulp van deze module kan men instellen welke sterkte de gebruikte paswoorden

op de website moeten hebben. Voor de huidige website zijn enkel sterke paswoorden

toegelaten. De functionaliteit wordt zichtbaar in het account menu van een gebruiker,

waar een gebruiker zijn paswoord kan veranderen. Bij de velden waarin men een

nieuw paswoord kan specificeren wordt aangeduid of het nieuwe paswoord aan de

gestelde eisen voldoet en indien dit niet zo is, welk soort karakter er nog moet worden

toegevoegd.

63

7.1.6 Profile Permission

Met behulp van deze module kan men per rol instellen welke velden een gebruiker kan

bekijken en aanpassen in het eigen account menu en welke velden hij kan aanpassen

in het account menu van een andere gebruiker.

7.1.7 Restrict Password Change

Deze module maakt het mogelijk om in te stellen dat een administrator enkel het eigen

paswoord kan veranderen en niet het paswoord van anderen.

7.1.8 Protect Critical Users

Deze module zorgt ervoor dat de super-user en de huidige ingelogde gebruiker niet

kunnen verwijderd worden. Voor onze site was het echter ook nodig dat het niet alleen

niet mogelijk mag zijn voor een administrator om zichzelf te verwijderen, het mag

eveneens niet mogelijk zijn om de eigen rol te veranderen. Daarom hebben wij zelf een

extra stukje code geschreven en dit toegevoegd aan de module.

Extra code:

// Indien men in de gebruikerspagina de rol wil veranderen

if (strpos($_GET['q'], 'admin/user/user') === 0) {

if (!empty($_POST['accounts']) && isset($_POST['operation']) &&

($_POST['operation'] == 'role_delegation_remove_role-3')) {

if (isset($_POST['accounts'][1])) {

drupal_set_message(t('Oeps! Je kan de rol van user #1 niet veranderen!'), 'error');

drupal_goto('admin/user/user');

}

else if (isset($_POST['accounts'][$user->uid])) {

drupal_set_message(t('Oeps! Je kan je eigen administratorrechten niet

veranderen!'), 'error');

drupal_goto('admin/user/user');

}}}}

7.1.9 Profile

In tegenstelling tot de andere modules, is deze module reeds verwerkt in de Drupal

core. Hij dient dus enkel te worden ingeschakeld. Deze module biedt ondersteuning

voor instelbare gebruikersprofielen. Via deze module kunnen extra velden aangemaakt

worden die zullen verschijnen in het account menu van een gebruiker. Men kan per

64

veld instellen of dit een verplicht of een optioneel veld is. Indien een administrator een

nieuwe gebruiker wil aanmaken zal hij deze velden ook reeds kunnen (optionele

velden) of moeten (verplichte velden) invullen. Men kan er bijvoorbeeld voor kiezen om

persoonlijke informatie, zoals de naam, toe te voegen aan het account menu van een

gebruiker.

7.2 EEN GEBRUIKER TOEVOEGEN

Via de Bizonwebsite is het niet mogelijk om zich te registreren. Enkel een medewerker

van Bizon vzw met de rol van administrator kan een gebruiker toevoegen.

Waarom niet iedereen zich zonder meer kan registreren spreekt voor zich. Vanaf het

moment dat een gebruiker geregistreerd is, krijgt deze namelijk toegang tot de

gegevens. Een andere mogelijkheid zou zijn om een controle in te bouwen. Men zou

de administrator elke registratie kunnen laten nakijken en goedkeuren alvorens een

gebruiker toegang krijgt tot de website. Dit zou de administrators met onnodig veel

werk opzadelen.

Hoewel er bij elke organisatie een zeker personeelsverloop is, alsook bij Bizon, blijft de

kern van medewerkers redelijk stabiel. Het sporadisch verwijderen of toevoegen van

een gebruiker vergt veel minder tijd en energie dan het voortdurend nakijken van

registraties. Om misbruik te voorkomen hebben we ervoor geopteerd om slechts een

beperkt aantal medewerkers de mogelijkheid te geven een gebruiker toe te voegen,

namelijk de medewerkers met de rol van administrator. Dit werd verwezenlijkt door

gebruik te maken van de module ‘Administer Users by Role’.

Wanneer men een gebruiker toevoegt dient de administrator een gebruikersnaam in te

geven. Om het beheer van de gebruikers te vereenvoudigen kiest men dan ook best

voor een gestandaardiseerde gebruikersnaam bv. de eerste letter van de voornaam

gevolgd door de familienaam. De gebruikersnaam dient verder uniek te zijn voor elke

gebruiker.

Voor deze nieuwe gebruiker dient er vervolgens een geldig e-mailadres opgegeven te

worden. Ook dit e-mailadres dient uniek te zijn.

Verder kan men de status van de account instellen (geblokkeerd/actief), de rol

(standaard geverifieerde gebruiker, optioneel administrator), de standaardtaal van de

e-mails (Engels/Nederlands) en de voor- en familienaam van de nieuwe gebruiker.

65

De meeste van deze velden zijn standaardvelden, behalve de velden rol en voor- en

familienaam. Voor de checkbox ‘rol’ toe te voegen aan de gebruikersregistratie pagina

werd gebruik gemaakt van de module ‘Role Delegation’. De velden voor- en

familienaam zijn verplicht en werden door ons geconfigureerd met behulp van de

module ‘Profile’.

Wanneer men deze nieuwe gebruiker toegevoegd heeft wordt er een e-mail verstuurd

naar het opgegeven e-mailadres.

In deze e-mail kan men de gebruikersnaam en een automatisch gegenereerd sterk

wachtwoord vinden. Dit wachtwoord kan uit veiligheidsoverwegingen niet gekozen

worden door de administrator. In deze e-mail werd er ook een eenmalige login

voorzien. Wanneer een gebruiker vervolgens voor het eerst hiermee inlogt wordt deze

automatisch doorgestuurd naar de pagina waar hij zijn wachtwoord kan wijzigen. Dit

werd gerealiseerd met behulp van de door ons aangepaste module ‘Generate

Password’.

7.3 GEBRUIKERSGEGEVENS WIJZIGEN

7.3.1 Geverifieerde gebruikers

Een gewone gebruiker heeft enkel toegang tot zijn eigen gegevens en kan via zijn

account enkel zijn wachtwoord en e-mailadres wijzigen.

De naam van de gebruiker verandert normaal gesproken niet en men kan deze dan

ook niet wijzigen. Indien dit toch nodig zou zijn, kan de naam wel gewijzigd worden

door een administrator. Dit werd geconfigureerd aan de hand van de module ‘Profile

Permission’.

Een gewone gebruiker is niet in staat om zichzelf of anderen de rol van administrator

toe te wijzen.

Wanneer een gewone gebruiker zijn of haar wachtwoord wenst te wijzigen dient dit een

sterk wachtwoord te zijn. Bij het ingeven van het nieuwe wachtwoord wordt er, per

ingevoerd teken, weergegeven welk soort karakters nog dienen toegevoegd te worden

opdat het wachtwoord een sterk wachtwoord zou zijn. Dit werd gerealiseerd dankzij de

module ‘Password Strength’.

Het nieuwe wachtwoord moet tweemaal worden ingevoerd. Hierbij wordt gecontroleerd

of deze twee wachtwoorden gelijk zijn aan elkaar. Indien dit niet het geval is moet men

het wachtwoord opnieuw invoeren. In Figuur 11 wordt er weergegeven hoe er

gecontroleerd word op een sterk wachtwoord.

66

Figuur 11: Sterk wachtwoord

Wanneer men klaar is met het wijzigen van de gegevens dient men het oude

wachtwoord in te voeren om de aanpassingen te bevestigen. Dit werd

geïmplementeerd om ervoor te zorgen dat niemand anders dan de gebruiker zelf zijn

gegevens kan aanpassen. Dit werd geconfigureerd aan de hand van de module

‘Password Change Confirm’.

7.3.2 Administrators

Wanneer een administrator zijn eigen gegevens wenst te wijzigen kan dit, net als bij

gewone gebruikers, via zijn account menu. Een administrator kan zijn eigen

gebruikersnaam en naam wijzigen, het e-mailadres, het wachtwoord en zijn status

(geblokkeerd/actief).

Net als bij gewone gebruikers dient het nieuwe wachtwoord een sterk wachtwoord te

zijn. Wanneer men de aanpassingen wenst door te voeren, dient men net als gewone

gebruikers, het oude wachtwoord op te geven.

Zoals reeds gezegd heeft een administrator ook de mogelijkheid om gegevens van

andere gebruikers te wijzigen. Dit kan door in de lijst van gebruikers, naast een

bepaalde gebruiker, op bewerken te klikken. Men kan voor de geselecteerde gebruiker

dan de persoonlijke informatie wijzigen zoals de naam en de voornaam, het e-

mailadres, de status (geblokkeerd/actief), de taalinstellingen en de tijdzone. Voordat

deze wijzigingen kunnen worden opgeslagen dient de administrator zijn wachtwoord op

te geven. Dit werd geconfigureerd aan de hand van de module ‘Password Change

Confirm’.

De administrator is echter niet bevoegd om het paswoord van een andere gebruiker te

veranderen. Hiervoor werd de module ‘Restrict Password Change’ gebruikt.

67

Een administrator kan administratorrechten toewijzen aan, of afnemen van, andere

gebruikers. Hiervoor werd de module ‘Role Delegation’ gebruikt.

Het dient te worden vermeden dat een administrator zijn eigen gebruikersrol kan

aanpassen. Men kan zichzelf dus de rol van administrator niet afnemen, enerzijds om

te vermijden dat men zichzelf per ongeluk de rechten afneemt en anderzijds om er

zeker van te zijn dat er minstens één gebruiker de rol van administrator bezit. Dit werd

gerealiseerd aan de hand van de door ons aangepaste module ‘Protect Critical Users’.

7.3.3 Een nieuw wachtwoord aanvragen

Indien een gebruiker zijn wachtwoord vergeten is, kan hij naar de inlogpagina van de

website surfen. In het kadertje van de gebruikerslogin kan men “Nieuw wachtwoord

aanvragen” aanklikken. Vervolgens kan de gebruiker zijn gebruikersnaam of e-

mailadres invullen. Er zal automatisch een nieuw wachtwoord worden gegenereerd en

verzonden naar het e-mailadres van de gebruiker.

7.4 EEN GEBRUIKER VERWIJDEREN

Gezien het niet wenselijk is dat ex-medewerkers van Bizon vzw nog steeds toegang

hebben tot de website moet het mogelijk gemaakt worden om gebruikers te

verwijderen. Enkel administrators kunnen gebruikers verwijderen.

Een mogelijk probleem is dat men, per ongeluk, een verkeerde gebruiker verwijdert.

Om dit te voorkomen moet de administrator, nadat hij een gebruiker geselecteerd heeft

en op verwijderen geklikt heeft, nogmaals bevestigen dat hij de geselecteerde

gebruiker wil verwijderen. Er wordt hierbij gewaarschuwd dat deze actie niet ongedaan

kan gemaakt worden.

Indien er geen administrator meer aanwezig zou zijn, zouden er geen gebruikers meer

toegevoegd of verwijderd kunnen worden. Om er zeker van te zijn dat er steeds

minstens één administrator is, is het niet mogelijk om de eigen account te verwijderen.

Dit werd mogelijk gemaakt door de module ‘Protect Critical Users’.

68

8. Besluit

De doelstelling van onze scriptie bestond uit twee delen. Enerzijds dienden we een

database te ontwerpen om de gegevens van Bizon vzw in op te slaan. Anderzijds

dienden we een web-applicatie te ontwerpen in Drupal, met dezelfde functionaliteiten

als de website van de groep van vorig jaar. Deze web-interface moet de medewerkers

van Bizon toelaten om gegevens toe te voegen, te bekijken, te wijzigen of te

verwijderen en voorzieningen toelaten om een aanvraag tot inschrijving in te dienen.

De databankstructuur werd opgezet na een grondige analyse van de behoeften van de

administratie van Bizon vzw. De databank werd vervolgens aan de hand van Drupal

geïmplementeerd in phpMyAdmin, een SQL database managementsysteem.

De web-applicatie zelf kwam tot stand na analyse van de functionaliteiten van de

bestaande website. Er werd net zoals de bestaande website een publiek en een privaat

deel voor de website ontwikkeld. In het publieke deel kunnen voorzieningen aan de

hand van hun klantennummer een aanvraag indienen. In het private deel kunnen

medewerkers van Bizon vzw data toevoegen, bekijken en manipuleren.

Bij de demonstratie van de website aan een medewerker van Bizon, bleek de website

te voldoen aan de gestelde eisen. Of de website ook operationeel wordt zal de

toekomst moeten uitwijzen, maar men leek alvast erg geïnteresseerd.

69

9. Referenties

9.1 BOEKEN

De Tré, G. (2007). Principes van databases. Pearson Education Benelux

Mercer, D. (2010). Drupal 7. Packt Publishing

Townsend, R.J. & Pakrul, S. (2010). Foundation Drupal 7. Friends of ED

VanDyk, J.K. (2008). Pro Drupal Development, second edition. Apress

9.2 WERKSTUKKEN

Schelstraete, G. & Jacobs, G. (2010). Webgestuurde deelnemersadministratie voor

een sociaal-toeristische jeugdvereniging. Vakgroep Telecommunicatie en informatie-

verwerking.

9.3 WEBSITES

MySQL (http://www.mysql.com)

Nederlandstalige Drupal gemeenschap (http://drupal.be)

Nederlandstalige Drupal-handboek website (http://www.drupalhandboek.nl)

Officiële Drupal website (http://drupal.org)

Persoonlijke website van Dries Buytaert (http://buytaert.net)

PHP (http://php.net)

phpMyAdmin (http://www.phpmyadmin.net)

Theme Garden (http://themegarden.org/drupal6)

Webgestuurde deelnemersadministratie voor een sociaal...

Documents

Transcript of Webgestuurde deelnemersadministratie voor een sociaal...