[PHP/Alg] Site en backend opzet

[ripexx]

Situatie schets
Het gaat om een site voor een lokale hockey club. Nu is er voor gekozen omdat het clubblaadje te duur werd, de meeste info via het web te gaan verspreiden. Om nu iedere keer wedstrijdschema's, nieuws enz aan te passen zal er een backend moeten zijn. Er is gekozen voor een site welke zal gemaakt worden in PHP met een MySQL db voor data opslag. Deze keuze ligt vast ivm met de beschikbare kennis binnen de ontwikkelaars.

Pakket van eisen
Door de ontwikkelaars en het bestuur is er een pakket van eisen vast gesteld waar aan de site zou moeten voldoen. Dit betekend dat er door het gehele kader (+/- 20 personen) er nieuws en andere relevante info moet worden geplaatst. Er is al een eerste versie die sinds jan 2003 online is, maar deze heeft een aantal beperkingen. Vandaar een nieuwe opzet. Via de site worden teams, wedstrijden, clubs, uitslagen, scheidsrechters, banners, poll's, trainingen enz enz dus ingegeven. Alles wat zich binnen de club afspeeld zou beschikbaar moeten worden voor de leden via het web.

Vragen

1. Uit eerder ervaringen is gebleken dat het rechten systeem niet goed functioneerd, met name omdat er geen duidelijke structuur in de bevoegheden zit. Zo zijn bepaalde mensen zeer druk bezig binnen de club en doen eigenlijk dus veel meer dan volgens de werkelijke functie of hebben meerdere functies. Nu is het zo dat een bepaald lid toegang krijgt tot een bepaalde backend module, maar aangezien er steeds meer opties komen binnen bepaalde modules geeft dit te veel problemen. LAs ik de methode van "role base rights" bekijk moet je voor elke mogelijek actie die je wilt doen rechten hebben, deze rechten worden samengevoeg in een "rol(e)" en dan worden er weer een of meerder personen aan die rol gekoppeld? Nu krijg je alleen de situatie dat er voor 20 kader leden er ongeveer 18 rollen nodig zijn. Dan concludeer ik dat dit dus geen oplossing is. Zijn er nog andere manieren, ik wil in ieder geval toe naar een situatie waarin er per actie een vorm van controle is ten opzichte van de rechten.
2. Als vervolg op vraag 1; heeft het maken en analyseren van een actie log voor jullie veel voordelen gehad of is het meer een feature voor als je tijd over hebt. Want alleen voor het terug zoeken van fouten heeft het verder niet veel nut, tenzij je de data gaat analyseren en heeft het dan wel nut?
3. Als laatste twijfel ik nog een beetje of de daadwerkelijke opzet en opbouw. Aangezien ik deze keer toch echt eens OOP wil gaan proberen mot ik dit ook gaan verwerken in de daad werkelijke structtur. De opzet zal ongeveer zo worden: vanuit een index worden de verschillende delen geladen zoals de rechten en opmaak en een start module. Is het nu handiger om voor elke module de classes apart te laden of een file te maken met daarin alle classes of toch meer fucntionele classes te maken.

Daarnaast zal ik me deze keer ook gaan verdiepen in OOP binnen PHP en in een Template Systeem, zodat de HTML voortaan gedaan kan worden door iemand anders. Tevens ben ik nog opzoek naar wat algemenere ervaring die men heeft opgedaan trijdens een wat groter project. Ik hoop dat ik hier wat meer ervaring en feedback kan krijgen.

[Verwijderd]

je praat over "maar" 20 mensen die editen.
Is het niet mogelijk minder 'rollen' te maken en dus sommige mensen teveel rechten te geven?
Er is denk ik wel sociale controle, moet echt alles zo stikt afgeschermd zijn?
zo ja.. dan houd ik verder mijn mond daarover

hmm 20 leden 18 rollen?
dan kun je het hele rollen/groepen gebeuren net zo goed overslaan en gewoon users autoriseren.
1user=1rol

[ Voor 5% gewijzigd door Verwijderd op 21-05-2003 20:53 ]

[Verwijderd]

Role Base Security is een goede oplossing vooor dergelijke rechtenissues. Ik kan me echter moeilijk voorstellen dat de 20 kaderleden echt allemaal verschillende dingen doen. Vaak hebben mensen een combinatie van rollen, bijv. trainer, begeleider, kaderid en secretaris. Als je de rechten van al deze rollen over elkaar legt, kom je tot een goede verzameling rechten vooor dat persoon.

Ook moet je bedenken dat je sommige leden best meer rechten kan geven dan ze precies nodig hebben. Als antwoord op vraag 2 is het namelijk erg zinvol om een audit systeem in te bouwen. In dat geval kan je achteraf altijd achterhalen wat door wie wanneer is uitgevoerd. Ik neem in ieder geval aan dat je dat bedoelde met 'actie log'. Als iemand zijn rechten misbruikt, kan je het herstellen en die persoon erop aanspreken. Alleen met zeer 'mission critical' zaken zoals kasbeheer zijn strakke rechten heel belangrijk.

Overigens is Smarty misschien een interessante template engine voor jou: http://smarty.php.net/

HTH

[Johnny]

Ik heb een groep van +30 mensen die allemaal evenveel rechten hebben en dat gaat goed, ze gaan heus niet elkaar's artikelen veranderen om elkaar te pesten of het systeem kapot te maken. Als ze dat zouden doen zou die persoon meteen alle rechten worden ontnomen.

Je zit nu namelijk ook met het probleem dat wanneer iemand ziek is of van functie veranderd je weer iemand anders rechten zal moeten toewijzen.

[ripexx]

Verwijderd schreef op 21 mei 2003 @ 20:58:
Role Base Security is een goede oplossing vooor dergelijke rechtenissues. Ik kan me echter moeilijk voorstellen dat de 20 kaderleden echt allemaal verschillende dingen doen. Vaak hebben mensen een combinatie van rollen, bijv. trainer, begeleider, kaderid en secretaris. Als je de rechten van al deze rollen over elkaar legt, kom je tot een goede verzameling rechten vooor dat persoon.

Ik wil duidelijk kunnen aan geven wat er mag, dus de een mag wel wedstrijdschema's bekijken maar niet editten, maar wel weer scheidsrechter toevoegen etc. Zo kan de een wel html gebruiken in post en andere mogen alleen een gestripte UBB-tags gebruiken. Daarnaast zal er ook een forum komen voor de backend waarin, dit is voorla bedoeld voor overleg tussen verschillende kaderleden.

Ook moet je bedenken dat je sommige leden best meer rechten kan geven dan ze precies nodig hebben. Als antwoord op vraag 2 is het namelijk erg zinvol om een audit systeem in te bouwen. In dat geval kan je achteraf altijd achterhalen wat door wie wanneer is uitgevoerd. Ik neem in ieder geval aan dat je dat bedoelde met 'actie log'. Als iemand zijn rechten misbruikt, kan je het herstellen en die persoon erop aanspreken. Alleen met zeer 'mission critical' zaken zoals kasbeheer zijn strakke rechten heel belangrijk.

Je wil niet weten hoe irritant het is als iemand weer de nieuws items trashed omdat deze te oud zijn Dus dat zijn allemaal kleine problemen die graag wil voorkomen. Daarnaast zal er een scheiding komen in tussen zaken die online staan (niet te bewerken) en zaken die klaar staan in de backend.

Overigens is Smarty misschien een interessante template engine voor jou: http://smarty.php.net/

HTH

Die kende ik nog niet, ik gebruik de site van PHP maar zeer zelden, heeft troouwens een leuke functie dat je toch eninge logica in je templates kan stoppen. Thx voor de tip.

Johnny schreef op 21 May 2003 @ 21:35:
Ik heb een groep van +30 mensen die allemaal evenveel rechten hebben en dat gaat goed, ze gaan heus niet elkaar's artikelen veranderen om elkaar te pesten of het systeem kapot te maken. Als ze dat zouden doen zou die persoon meteen alle rechten worden ontnomen.

Je zit nu namelijk ook met het probleem dat wanneer iemand ziek is of van functie veranderd je weer iemand anders rechten zal moeten toewijzen.

Er zullen drie admins rond lopen die toegang hebebn tot alle modules en deze kunnen bij springen waarnodig, zij zullen ook rechten uit delen enz. Vaak worden bepaalde acties gedaan uit onwetendheid, dit is nog lastiger aan te pakken dan opzet omdat mensen niet eens weten dat ze iets fout hebben gedaan.

[ Voor 18% gewijzigd door ripexx op 21-05-2003 21:42 . Reden: reactie op Johnny ]

[Harm]

ripexx schreef op 21 May 2003 @ 21:38:
[...]

Je wil niet weten hoe irritant het is als iemand weer de nieuws items trashed omdat deze te oud zijn Dus dat zijn allemaal kleine problemen die graag wil voorkomen. Daarnaast zal er een scheiding komen in tussen zaken die online staan (niet te bewerken) en zaken die klaar staan in de backend.

Dit kun je oplossen door een nieuwsding dan niet daadwerkelijk te verwijderen maar alleen op onzichtbaar te zetten. Via DB-toegang kan zo'n ding dan altijd weer zichtbaar gemaakt worden. Voorbeeldje: een kolom 'visible' in je tabel opnemen en daarin aangeven of hij verwijderd is of niet.

[ripexx]

Harm schreef op 21 mei 2003 @ 22:42:
[...]

Dit kun je oplossen door een nieuwsding dan niet daadwerkelijk te verwijderen maar alleen op onzichtbaar te zetten. Via DB-toegang kan zo'n ding dan altijd weer zichtbaar gemaakt worden. Voorbeeldje: een kolom 'visible' in je tabel opnemen en daarin aangeven of hij verwijderd is of niet.

Klopt, dit zit er nu in via een omweg, maar is een van de zoveel zaken waar je tegen aanloopt als je zoiets begint op te zetten, hetzelfde zal ook opgaan voor de wedstrijden enz. In principe mag niemand iets uit de db verwijderen, behalve de db beheerder. Maar zijn er nog tips die ik over het hoofd heb gezien of war ik aan moet denken?