[alg]Effectieve workflow met user roles

[Verwijderd]

Ik sta momenteel voor een dilemma waar ik graag input hetzij suggesties voor wil hebben.

Ik ben momenteel bezig met het verder uitontwikkelen van een roll based systeem, waarbij er user roles zijn als author, editor, en publisher.

Er bestaat de mogelijkheid om acties van een user role eerst te laten controleren door een hoger persoon "in rang". Zo zal bijvoorbeeld de author een artikel schrijven, deze vervolgens in een wachtrij voor authorization zetten waarna de gemachtigde persoon het artikel kan controleren, en vervolgens live kan plaatsen, hetzij nogmaals doorsturen aan een nog hoger persoon "in rang". Met andere woorden er wordt een workflow gecreerd.

Nu zit hem het dilemma bij de authorization. Ik kan per account in een extra column van de database het ID van de persoon aan wie toestemming gevraagd moet worden, toevoegen. Maar wat als deze persoon geen toestemming kan geven als deze ziek is, of een vrije dag heeft? Dan zal de que van deze persoon vollopen en het artikel blijven hangen. Niet echt efficient dus, zeker niet bij content wijzigingen met spoed.

Nu zou je zeggen, iedereen met een hogere rang dan de author mag authorizen. Waar ik dan bang voor ben, is dat het tevens niet efficient meer zal zijn. Authorizing loopt langs elkaar heen, en workflow loopt ipv lineair kriskras door elkaar heen.

Iemand ideeen?..

[Verwijderd]

je moet aangeven of een een persoon beschikbaar is (ziek, vrij etc).
dan kun je de werkvoorraad van de niet beschikbare persoon verdelen over personen die wel beschikbaar zijn.
dit toedelen bijv. aan gebruikers met dezelfde rang, of via groepen etc.
Alleen toedelen van dat werk dat dezelfde dag ("met spoed") af moet.

beetje kort omschreven maar idee lijkt me duidelijk.

[Verwijderd]

Op dinsdag 12 februari 2002 11:22 schreef sjako het volgende:
je moet aangeven of een een persoon beschikbaar is (ziek, vrij etc).
dan kun je de werkvoorraad van de niet beschikbare persoon verdelen over personen die wel beschikbaar zijn.
dit toedelen bijv. aan gebruikers met dezelfde rang, of via groepen etc.
Alleen toedelen van dat werk dat dezelfde dag ("met spoed") af moet.

beetje kort omschreven maar idee lijkt me duidelijk.

Maar dit werkt helaas alleen met een systeem wat op vaste werktijden actief is. Stel dat ik 's nacht om 3 uur wat wil toevoegen, ik plaats het in de wachtrij niet wetende dat de persoon eigenlijk ziek is

[chem]

tsja... dit zijn de dingen waar je na 4 rewrites erachter komt dat het allemaal veel simpeler kon

Als ik je goed begrijp, wil je een systeem waar bij je objecten een 'parent' geeft (of andersom: 'childs'), en er daarin enige vrijheid moet zijn.

Ik zou kijken of je niet een standaard parent/child systeem kan uitbreiden met weging: dus een volgorde van objecten die 'meer' of 'minder' parent zijn.

Laat anders weten wat je huidige idee is?

[Nielsz]

Bij onze software, is het mogelijk om iemand zijn taken over te laten nemen als hij ziek is. In een admin functie kan je dan een gebruiker selecteren waar (in dit geval) de mail nu heengestuurd gaat worden. (gewoon een extra veld in de db dus).

[chem]

Op dinsdag 12 februari 2002 11:24 schreef Gordijnstok het volgende:

[..]

Maar dit werkt helaas alleen met een systeem wat op vaste werktijden actief is. Stel dat ik 's nacht om 3 uur wat wil toevoegen, ik plaats het in de wachtrij niet wetende dat de persoon eigenlijk ziek is

daarom moet je de user er niet mee opschepen wie de 'parent' moet zijn. Dit moet on-the-fly worden bepaald. Stel dat Harrie om 4 uur dat stuk wil authorizen, dan moet dat ook kunnen maar als hij 's ochtends ziek blijkt, moet hij zichzelf voor een bepaalde periode kunnen 'flaggen' als een parent met een zeer lage weging (nul?)

[Floor-is]

Ik ben ook een beetje met Gordijnstok aan het babbelen over hoe het op T.net gaat.

Wij hebben bijvoorbeeld gemerkt dat het niet goed werkt als maar 1 persoon een item kan goedkeuren. Daar zijn dan ook meerdere personen voor.

We werken met een redactiesysteem, er zijn een x-aantal (4 bij ons volgens mij) die diensten draaien. (Ma-ochtend, -middag en -avond bijvoorbeeld.) De redacteuren houden dus de kwaliteit in de gaten. Hiernaast hebben we een tweetal coordinatoren, welke wekelijks alle nieuwsposts evalueren.

[Verwijderd]

Op dinsdag 12 februari 2002 11:24 schreef Gordijnstok het volgende:

[..]

Maar dit werkt helaas alleen met een systeem wat op vaste werktijden actief is. Stel dat ik 's nacht om 3 uur wat wil toevoegen, ik plaats het in de wachtrij niet wetende dat de persoon eigenlijk ziek is

Dan moet je je workflow proces eens goed uitschrijven.
Als jij 's nachts iets toe wilt voegen zal er toch iemand moeten zijn die accordeerd. Je werkt dus 24 uur per dag (vaste werktijden).

Die iemand zal niet 24 uur per dag werken dus je zult altijd meerdere personen moeten hebben die kunnen accorderen.

[Verwijderd]

Ik denk dat ik de meest verstandige oplossing als volgt zou zijn. Er wordt 1 publisher toegewezen per author, zodat de publisher over het algemeen overzicht houdt over de resultaten/value van de author.

Author schrijft artikel, submit deze, en het artikel wordt vervolgens in de que geplaatst bij de publisher verbonden aan de author. Zodra de publisher ziek is, bestaat er de mogelijkheid om de que vrij te geven in 2 opties.

1) Maak que public voor alle publisher
2) Wijs volledige que toe aan een andere publisher

Nu is een publisher ervaren genoeg om andermans que over te nemen. Per slot van rekening heeft hij ook de verantwoordelijkheid om zaken live te zetten. Zodra een andere publisher doorkrijgt dat een mede-publisher ziek is, kan de publisher acties uitvoeren op de hangende que van zijn kermende collega.

Probleem is nu alleen nog .. wat als er maar 1 publisher is. Ik denk dat ik daarvoor iets bedenk met een soort van code voor noodgevallen. Zodra een author deze code intypt via het CMS, wordt zijn account role van author tijdelijk verhoogd naar die van publisher.

slim idee?

[Verwijderd]

Op dinsdag 12 februari 2002 11:32 schreef sjako het volgende:

[..]

Dan moet je je workflow proces eens goed uitschrijven.
Als jij 's nachts iets toe wilt voegen zal er toch iemand moeten zijn die accordeerd. Je werkt dus 24 uur per dag (vaste werktijden).

Die iemand zal niet 24 uur per dag werken dus je zult altijd meerdere personen moeten hebben die kunnen accorderen.

Een voorbeeld als T.net denk ik dan aan. Posts kunnen 24x7 gemaakt worden door Authors als ze wat leuks tegenkomen.

[Pelle]

Ik zou voor een oplossing in groepen gaan. Ik weet niet hoe belangrijk het is dat een author altijd dezelfde 'supervisor' heeft, maar zoals ik het zelf inschat lijkt me dat niet echt van belang.

Alle supervisors van een bepaalde rang kunnen bij hetzelfde overzicht van artikelen, en op het moment dat een supervisor een artikel onder de loep neemt om 't, wordt het geflagged op 'afblijven, ik kijk er nu naar'. Zo voorkom je dat andere supervisors met hetzelfde artikel aan de haal gaan. Vervolgens kan zoiemand het artikel een andere flag geven: 'wil iemand anders hier eens naar kijken', 'doorgesluisd naar boven', 'afgewezen', 'live gezet', 'teruggestuurd', enz.

Ziekte wordt pas een probleem als alle supervisors ziek zijn, iets wat ik niet waarschijnlijk acht overigens, maar waar je dus wel even naar moet kijken. Als er een hele groep ziek of afwezig is, zal een nog hoger niveau daarvan op de hoogte gesteld moeten worden, en hun zullen moeten bepalen wat er moet gebeuren: alle artikelen doorsluizen naar boven, of lekker in de queue laten staan voor het onderliggende niveau.

[Verwijderd]

Maar ik vraag me af wat de nadelen zijn van het groepsgewijs coordineren van artikelen die ge-published mogen worden. Ik vraag me af of dit fout kan gaan en op welke manier en met welke gevolgen. Want wat er fout kan gaan gaat ooit eens fout

[Nielsz]

Wij hebben dus een systeem wat per afdeling een aantal managers heeft. documenten kan je naar een afdeling of naar een persoon sturen. Als je 'm naar een afdeling stuurt, komt hij bij de manager aan, die dan moet bekijken wie er tijd heeft om 'm af te handelen. Hij kan 'm naar een ziek persoon sturen, maar dan staat er in de db wie zijn taken overneemt.

Dan kan je in de admin natuurlijk nog instellen wat er moet gebeuren als hij beter is: "niet afgehandelde docu's terugsturen van de 'overnemer' naar de originele persoon", of hem ze gewoon laten afhandelen.

[Verwijderd]

Op dinsdag 12 februari 2002 11:41 schreef Nielsz het volgende:
Wij hebben dus een systeem wat per afdeling een aantal managers heeft. documenten kan je naar een afdeling of naar een persoon sturen. Als je 'm naar een afdeling stuurt, komt hij bij de manager aan, die dan moet bekijken wie er tijd heeft om 'm af te handelen. Hij kan 'm naar een ziek persoon sturen, maar dan staat er in de db wie zijn taken overneemt.

Dan kan je in de admin natuurlijk nog instellen wat er moet gebeuren als hij beter is: "niet afgehandelde docu's terugsturen van de 'overnemer' naar de originele persoon", of hem ze gewoon laten afhandelen.

Maar op welke manier kan worden aangegeven dat een publisher ziek is. Mensen zijn vaak vergeetachtig, en als ik per dag een flinke lading artikelen in de que plaats, en de publisher vergeet zich ziek te melden is er dus een probleem. Dan hangt die que.

[Pelle]

Op dinsdag 12 februari 2002 11:34 schreef Gordijnstok het volgende:
Probleem is nu alleen nog .. wat als er maar 1 publisher is. Ik denk dat ik daarvoor iets bedenk met een soort van code voor noodgevallen. Zodra een author deze code intypt via het CMS, wordt zijn account role van author tijdelijk verhoogd naar die van publisher.

Hier zat ik ook aan te denken, maar op het moment dat je users rechten geeft die ze normaal niet hebben, ondermijn je het hele idee van die rechten natuurlijk.

Nu strekken die rechten niet verder dan het beoordelen van eigen werk, maar ik vraag me dus af in hoeverre je dat wilt, en in hoeverre je je een author verantwoordelijk kunt houden voor het publiceren van z'n eigen werk. Ik weet verder geen achtergronden van de klant voor wie je het bouwt, maar ik kan me een hoop situaties voorstellen dat dat absoluut niet gewenst is.

[Verwijderd]

Op dinsdag 12 februari 2002 11:43 schreef Gordijnstok het volgende:

[..]

Maar op welke manier kan worden aangegeven dat een publisher ziek is. Mensen zijn vaak vergeetachtig, en als ik per dag een flinke lading artikelen in de que plaats, en de publisher vergeet zich ziek te melden is er dus een probleem. Dan hangt die que.

dus geen que per persoon maar per groep.
of een soort overflow inbouwen, als je niet aan groepen wilt beginnen.

[Verwijderd]

Op dinsdag 12 februari 2002 11:44 schreef Pelle het volgende:

[..]

Hier zat ik ook aan te denken, maar op het moment dat je users rechten geeft die ze normaal niet hebben, ondermijn je het hele idee van die rechten natuurlijk.

Nu strekken die rechten niet verder dan het beoordelen van eigen werk, maar ik vraag me dus af in hoeverre je dat wilt, en in hoeverre je je een author verantwoordelijk kunt houden voor het publiceren van z'n eigen werk. Ik weet verder geen achtergronden van de klant voor wie je het bouwt, maar ik kan me een hoop situaties voorstellen dat dat absoluut niet gewenst is.

Dit project is niet voor een klant, dit is meer een project voor zelfstudie, waarbij ik een webbased redactioneel systeem bouw met zoveel mogelijk opties erin

Wat betreft die code, tja, het is inderdaad wel zo dat de kans bestaat dat een author niet goed kan omgaan met die rechten, anders was die zowiezo wel publisher geweest.

Hoe wordt zoiets bij zeg maar de krant geregeld. Ik neem aan dat een groep authors daar ook maar 1 persoon heeft als aanspreekpunt.

[Nielsz]

Op dinsdag 12 februari 2002 11:43 schreef Gordijnstok het volgende:

[..]

Maar op welke manier kan worden aangegeven dat een publisher ziek is. Mensen zijn vaak vergeetachtig, en als ik per dag een flinke lading artikelen in de que plaats, en de publisher vergeet zich ziek te melden is er dus een probleem. Dan hangt die que.

Een publisher is niet meer dan een gebruiker met een vinkje "isPublisher" in zijn profiel. En die kan dus ook zich ziek melden en vervanging krijgen. En als die ziek is, kan hij ook vervanging krijgen, en die ook, en die ook, ...

Dan kan je ook nog een gebruikerinstelling maken dat je een mail krijgt als de que te vol is.

[Verwijderd]

Op dinsdag 12 februari 2002 11:54 schreef Nielsz het volgende:

[..]

Een publisher is niet meer dan een gebruiker met een vinkje "isPublisher" in zijn profiel. En die kan dus ook zich ziek melden en vervanging krijgen. En als die ziek is, kan hij ook vervanging krijgen, en die ook, en die ook, ...

Dan kan je ook nog een gebruikerinstelling maken dat je een mail krijgt als de que te vol is.

Wat zijn bij jullie de ervaringen met een dergelijke contructie. Hoe is de reactietijd, werkverdeling, efficientie en overzicht bij jullie systeem?

[Nielsz]

Op dinsdag 12 februari 2002 11:46 schreef Gordijnstok het volgende:
[..]
Hoe wordt zoiets bij zeg maar de klant geregeld. Ik neem aan dat een groep authors daar ook maar 1 persoon heeft als aanspreekpunt.

Elke afdeling heeft een supervisor. Deze kan dus documenten doorsturen, mensen ziek melden, rapportages bekijken. Hij moet ervoor zorgen dat zijn afdeling goed loopt. Is hij ziek, dan moet er iemand anders zijn afdeling waarnemen. Hetzij de baas van het bedrijf, de afdelingschef ernaast of 'chef koffie'.

[Nielsz]

Op dinsdag 12 februari 2002 11:55 schreef Gordijnstok het volgende:

[..]

Wat zijn bij jullie de ervaringen met een dergelijke contructie. Hoe is de reactietijd, werkverdeling, efficientie en overzicht bij jullie systeem?

Misschien handiger om ff uit te leggen wat ons systeem doet
We werken voor woningcoperaties; en handelen de poststroom. Stel er komt een brief binnen met een klacht: "straat 1a: de schoorsteen is kapot. Fix het eikels!". Deze brief komt in het archief van de huurder, en in het archief van het huis. Omslachtig dus.
Dus het wordt allemaal in de computer gezet. Nu komt een zelfde brief binnen. Chef prutser scanned 'm in. Noteert (oa) de 'indexgegevens' (huisnummer,huurdersnummer), en hij gaat naar de 1e que.
Iemand anders zit bij die que te wachten, en zegt: ah, een klacht; deze moet naar de afdeling klachten. Ze stuurt 'm naar de manager (of direct de persoon), en die stuurt 'm door naar Johan, die daar specialist in is. Tevens geeft hij mee dat het vandaag afgehandeld moet zijn.
Johan leest het, doet z'n ding, en geeft aan het document de status afgehandeld.
Is Johan ziek, komt hij automatisch bij Piet terecht.

Dit systeem werkt perfect voor bedrijven waar 2 man CONTINUE ingekomen brieven lopen in te scannen. Dus er gaat redelijk veel post doorheen.

Zo redelijk duidelijk?

[Verwijderd]

Ja, maar het opvangen van de que automatisch laten verlopen is niet zo groot als er 2 personen zijn die zich ziek kunnen melden via het systeem, maar als je +20 mensen hebt, dan zie ik nog wel eens problemen optreden bij mensen die zich niet ziek melden.

[Verwijderd]

zoals ik al zei : overflow (op tijd/ aantal)

[Nielsz]

Op dinsdag 12 februari 2002 12:07 schreef Gordijnstok het volgende:
Ja, maar het opvangen van de que automatisch laten verlopen is niet zo groot als er 2 personen zijn die zich ziek kunnen melden via het systeem, maar als je +20 mensen hebt, dan zie ik nog wel eens problemen optreden bij mensen die zich niet ziek melden.

Dat is toch de taak van een manager?
Verder is het zo dat je het werk van +20 personen niet goed kan afhandelen door een mooi workflow systeempje te bouwen
Oftewel: je kan nog zo'n mooi systeem bouwen, maar als iedereen zich ziek meld ben je nog nergens.

[Verwijderd]

Op dinsdag 12 februari 2002 12:09 schreef sjako het volgende:
zoals ik al zei : overflow (op tijd/ aantal)

Dus als ik het goed begrijp, raad je een systeem aan gekoppeld aan een kalender. Op deze kalender is aangegeven wanneer iemand niet beschikbaar is.

Alvorens de que te vullen met het artikel, wordt de kalender gecontroleerd op data en tijden dat de que niet gevuld mag worden bij de persoon.

[Verwijderd]

nee, als er bijvoorbeeld niet binnen 2 uur gereageerd wordt op een melding, dan werk herverdelen naar andere beschikbare personen.

of als er meer dan 20 dingen in de que staan herverdelen naar personen met minder in de que

[Crazy D]

Op dinsdag 12 februari 2002 11:41 schreef Gordijnstok het volgende:
Maar ik vraag me af wat de nadelen zijn van het groepsgewijs coordineren van artikelen die ge-published mogen worden. Ik vraag me af of dit fout kan gaan en op welke manier en met welke gevolgen. Want wat er fout kan gaan gaat ooit eens fout

Uhmm dat 1 persoon een document afkeurd, en de ander 'm online zet?
Bij een niet nader te noemen bedrijf is er op die manier een keer een document verschenen op de frontpage dat er een nieuwe directeur was voor een divisie, terwijl de gesprekken juist gesloten waren omdat ze er toch niet uitkwamen. Maar het document was al wel aangemaakt, alleen even 'on hold' gezet (dat was de bedoeling...).
Had perfect voorkomen kunnen worden trouwens als de betreffende mensen netjes de afspraken hadden gevolgt, en dus opmerkingen hadden geplaatst in het daarvoor bestemde invoervak, mjah mensen kunnen dat vergeten...

Maar ik vraag me af of zoiets met een ander rollen-systeem niet had gebeurt. De maker van het document had deze nooit mogen realizen (waardoor deze bij de volgende groep terecht kwam) terwijl de onderhandelingen nog niet rond waren. De persoon die 'm online heeft gezet, had inhoudelijk moeten kijken, maar ging er vanuit dat de persoon die het document had aangemaakt alles had gecontrolleerd, en dat alles klopte.

[Wouter Tinus]

De DSP van Tweakers.net is ook voorzien van een uitgebreid rechtensysteem. Per account zijn er een stuk of 30 eigenschappen die ingesteld kunnen worden, helaas werkt het (nog) niet met groepen. Mijn advies: ZEKER DOEN, anders raak je het overzicht snel kwijt.

Per user kan bijvoorbeeld ingesteld worden of hij zijn werk zelf op de frontpage mag zetten, of hij werk van anderen mag aanpassen en of hij werk van anderen mag verwijderen. Bovendien kan gekozen worden of iemand nieuws mag doen, of reviews, of frontpage etc. etc. etc.

Omdat we niet in een 9-17 kantoorsituatie zitten, maar in een 24-7 omgeving willen we de nieuwsposters zoveel mogelijk vrijheid geven. D.w.z.: na een proef/trainingsperiode mogen ze zelf hun werk online zetten. Er is dus wel nacontrole, maar geen voorcontrole . We willen het aanmoedigen om b.v. 's nachts en 's morgens te posten, maar dat werkt niet als er op dat moment niemand met meer rechten aanwezig is. Nieuwsposters met rechten om andermans werk aan te passen kunnen artikelen van 'newbies' online zetten. De coördinatie is hiervoor eindverantwoordelijk, maar wordt natuurlijk ook geholpen om te voorkomen dat het te lang duurt.

Wèl wordt door een aparte groep mensen bepaald over welke onderwerpen geschreven moet worden. De 5-koppige redactie zorgt ervoor dat de nieuwsposters altijd iets te doen hebben, wanneer ze ook inloggen. Dit gaat via een vast rooster. Om alles consequent te houden kunnen normale nieuwsposters geen submits verwijderen, geen items aan de verwerkqueue toevoegen, en geen items eruit verwijderen.



De pijlen vanuit de submitqueue is werk dat alleen door de redactie (de 'hoogste' nieuwsposters) wordt verricht. De nieuwsqueue is een buffer, en de pijlen van de buffer naar de frontpage kan door iedereen worden gedaan.

Door de buffer altijd vol te houden en goede afspraken te maken kun je mensen de vrijheid geven om te posten wanneer ze maar willen, zonder dat er steeds actieve controle plaats hoeft te vinden.

[Nielsz]

Op dinsdag 12 februari 2002 12:21 schreef Wouter Tinus het volgende:


Omdat we niet in een 9-17 kantoorsituatie zitten, maar in een 24-7 omgeving willen we de nieuwsposters zoveel mogelijk vrijheid geven. D.w.z.: na een proef/trainingsperiode mogen ze zelf hun werk online zetten. Er is dus wel nacontrole, maar geen voorcontrole . We willen het aanmoedigen om b.v. 's nachts en 's morgens te posten, maar dat werkt niet als er op dat moment niemand met meer rechten aanwezig is. Nieuwsposters met rechten om andermans werk aan te passen kunnen artikelen van 'newbies' online zetten. De coördinatie is hiervoor eindverantwoordelijk, maar wordt natuurlijk ook geholpen om te voorkomen dat het te lang duurt.

Een nieuwe nieuwsposter kan dus snachts alleen maar posts op de fp zetten als een 'manager' de laatste 15 minuten een pageview heeft gehad ofzo?

[Verwijderd]

Ik denk dat ik er een beetje uit ben, probeer mijn onderstaande oplossing te tackelen op alles wat je maar kunt bedenken Ik ervaar alles als opbouwende kritiek die tot een beter systeem kan leiden

Er bestaan 2 soorten que's.
1) Que's gebonden aan publishers
2) Que's die public zijn voor alle publishers

Elke author krijgt 1 publisher toegewezen. Dit kan dus 1 publisher zijn voor meerdere authors. Zodra de author zijn artikel invoert, komt deze in de que bij zijn/haar publisher te staan.

Er wordt een date en timestamp meegegeven. Als er door de publisher binnen deze limiet geen actie wordt ondernomen op het item in zijn que zal deze worden verplaatst naar de public que. op dat moment krijgen alle publishers de mogelijkheid actie te ondernemen.

Om het moment van actie wordt uiteraard het item op "flagged out" gezet, en kan het niet geopend worden door andere publishers.

Bij elke item kan een prioriteit worden meegegeven door de author. Items met prioriteit "urgent" of "immediate" of iets dergelijks worden meteen in de public que gezet zodat er asap respons op kan worden gegeven.

Zo vang ik het probleem van afwezige publishers op door automatisch de que bij limietsoverschrijding public te maken, en hou ik toch de verantwoordelijkheden zoveel mogelijk bij 1 publisher zodat aanspreekpunten niet verwazigen.

[Crazy D]

Op dinsdag 12 februari 2002 12:25 schreef Nielsz het volgende:
Een nieuwe nieuwsposter kan dus snachts alleen maar posts op de fp zetten als een 'manager' de laatste 15 minuten een pageview heeft gehad ofzo?

Hij kan 'm submitten alleen moet iemand met meer rechten deze nog eerst approven.
Tenminste, zo lees ik dat...

[Nielsz]

Gordijnstok: dus na '2' uur, kan iedereen chef 'm goedkeuren? Ook chef administratie? Is het niet handig om elke publisher een default publisher mee te geven als hij ziek is? Dan gaat hij gewoon het rijtje allemaal af.

[Verwijderd]

Op dinsdag 12 februari 2002 12:33 schreef Nielsz het volgende:
Gordijnstok: dus na '2' uur, kan iedereen chef 'm goedkeuren? Ook chef administratie? Is het niet handig om elke publisher een default publisher mee te geven als hij ziek is? Dan gaat hij gewoon het rijtje allemaal af.

Ja dat klopt. In mijn visie is een publisher iemand die weet wat hij doet, en kan omgaan met de verantwoordelijkheden die daarbij horen. Als ik namelijk nog meer publishers ga koppelen aan een author kom ik in een visieuze cirkel terecht waarbij het mogelijk is dat alle publishers gekoppeld aan de author ziek zijn, afspraken hebben, kortom niet kunnen authorizen.


Pelle kwam met de vraag? Maar dan gaan authors als de Publisher er niet is alles wat ze posten op urgent zetten. Daar heeft hij gelijk in betreft een kantooromgeving. Je ziet immers je "baas" niet op zijn werkplek zitten. Maar daar moeten gewoon afspraken over worden gemaakt, dat niet zomaar de status urgent kan worden meegegeven.

Voor een transparante werkomgeving als het web, weet de author niet dat de publisher er niet is. Dit krijgt hij niet te zien, hij krijgt ook de que niet te zien.

Als ik nu als poster een bericht post op T.net, weet ik niet of zeg maar Floris aanwezig is om toestemming te verlenen, dus zie ik geen problemen met een overrun van de public que.

[Nielsz]

Op dinsdag 12 februari 2002 12:36 schreef Gordijnstok het volgende:
[..]
Ja dat klopt. In mijn visie is een publisher iemand die weet wat hij doet, en kan omgaan met de verantwoordelijkheden die daarbij horen. Als ik namelijk nog meer publishers ga koppelen aan een author kom ik in een visieuze cirkel terecht waarbij het mogelijk is dat alle publishers gekoppeld aan de author ziek zijn, afspraken hebben, kortom niet kunnen authorizen.
Als ik nu als poster een bericht post op T.net, weet ik niet of zeg maar Floris aanwezig is om toestemming te verlenen, dus zie ik geen problemen met een overrun van de public que.

Een publisher weet wat hij doet, in zijn vakgebied. Mij zal je ook niet zien in AMD-INTEL flamewars, snappie? Dus het is voor mij onnodig om die in mijn queu te zetten.
En die visieuze cirkel wordt automatisch opgeheft als er iemand weer aanwezig is.

En het ligt eraan of het over TweakDSL gaat, want dan wil je dat niemand anders die kan publishen, ook al is floris ziek. Alleen floris mag die publishen.

[Verwijderd]

Op dinsdag 12 februari 2002 12:42 schreef Nielsz het volgende:

[..]

Een publisher weet wat hij doet, in zijn vakgebied. Mij zal je ook niet zien in AMD-INTEL flamewars, snappie? Dus het is voor mij onnodig om die in mijn queu te zetten.
En die visieuze cirkel wordt automatisch opgeheft als er iemand weer aanwezig is.

En het ligt eraan of het over TweakDSL gaat, want dan wil je dat niemand anders die kan publishen, ook al is floris ziek. Alleen floris mag die publishen.

Dan kun je een extra optie toevoegen, nl. het locken van een que item aan de publisher ongeacht de tijdslimiet

[Nielsz]

Op dinsdag 12 februari 2002 12:44 schreef Gordijnstok het volgende:

[..]

Dan kun je een extra optie toevoegen, nl. het locken van een que item aan de publisher ongeacht de tijdslimiet

En als nu alleen floris,daniel,femme deze mogen publishen?

oplossing: het document aan floris hangen, en als hij ziek is, aan de groep 'management' gooien.

[Verwijderd]

Op dinsdag 12 februari 2002 12:46 schreef Nielsz het volgende:

[..]

En als nu alleen floris,daniel,femme deze mogen publishen?

oplossing: het document aan floris hangen, en als hij ziek is, aan de groep 'management' gooien.

Dan krijg je dus onder de optie locken 2 stromingen. Lock aan publisher, en lock aan een specifieke groep

[Nielsz]

Op dinsdag 12 februari 2002 12:48 schreef Gordijnstok het volgende:

[..]

Dan krijg je dus onder de optie locken 2 stromingen. Lock aan publisher, en lock aan een specifieke groep

Of users en groups in 1 tabel zetten ("isGroup");

[Verwijderd]

Hier stond een brak dbmodel

[Verwijderd]

Op dinsdag 12 februari 2002 12:46 schreef Nielsz het volgende:

[..]

En als nu alleen floris,daniel,femme deze mogen publishen?

oplossing: het document aan floris hangen, en als hij ziek is, aan de groep 'management' gooien.

Overigens betekent dit dus dat je een dubbele groepering aanbrengt. Dus dat je zeg maar de volgende structuur krijgt en om even in de trant van T.net te blijven.


Afdeling Hardwarenieuws
- Publishers
- Authors

Afdeling Softwarenieuws
- Publisher
- Authors

Elke afdeling heeft dus zijn eigen stroming wederom. En zo krijgen publishers van de verschillende afdelingen niet elkaars public que te zien, tenzij het item de status "urgent" heeft.

Dwz 2 extra tabels. Een table met stromingen van content, en een table met policies, gekoppeld aan stroming. Zo kan een account dus meerdere policies hebben, maar maximaal 1 policy per stroming

Oftewel je gaat tevens een selectie maken op werkgebied ter bevordering van de efficientie.

[Nielsz]

Tevens bedacht ik net dat het ook handig is dat je niet aangeeft wie 'm moet publishen, maar gewoon dus gewoon aangeeft wat voor docu het is. Dus je geeft aan dat het een klacht is, en het komt automatisch bij a) de manager of b) de directe persoon binnen.

[Verwijderd]

Op dinsdag 12 februari 2002 13:53 schreef Nielsz het volgende:


Tevens bedacht ik net dat het ook handig is dat je niet aangeeft wie 'm moet publishen, maar gewoon dus gewoon aangeeft wat voor docu het is. Dus je geeft aan dat het een klacht is, en het komt automatisch bij a) de manager of b) de directe persoon binnen.

Maar of dit handig kan zijn bij een redactioneel systeem vraag ik me af. Dit is meer handig bij een ticketing systeem lijkt me

[oh,when?]

Dan nog even de workflow in onze organisatie:



Zoals je ziet werken wij met groepen. Iedere groep heeft zo zijn eigen rechten, en privileges. Een redacteur kan hoort bij ons tot een groep, of hij kan bij meerdere groepen horen. Daarnaast kan een redacteur nog speciale rechten hebben. Tot zover niks bijzonders.

Als een redacteur een stukje afheeft, dan submit hij deze naar de Content-Queue. Hier gebeurt het echte werk. Nu vinden er een bepaald aantal processen plaats:


• Als de hoofdredacteur aanwezig is, dan bepaalt deze of het artikel geschikt is bevonden (approved)
• Mocht deze ziek zijn, dan is er een plaatsvervangend hoofdredacteur
• Nu is het mogelijk dat deze beide niet aanwezig zijn, dag vrij, etc etc, dan gaat de Content-Queue automatisch kijken. Dit gebeurt aan de hand van een aantal stricte regels. Dan kun je denken aan of het van een vaste redacteur komt, of deze in de goede groep wil posten, heeft hij de juiste rechten, etc.
• Als het bericht voldoet, dan krijgt deze de status approved mee, en kan deze vervolgens verder verwerkt worden ( zend een mailing uit, plaats online, etc)

Dit zou eventeel nog verder uitgebreid kunnen worden, bijv als een bericht niet voldoet, deze word doorgestuurd naar een projectmanager.

Daarnaast heeft een redacteur de mogelijkheid, om bij hoge spoed een bericht direct online te plaatsen. Echter dit zal men moeten verantwoorden later.

HTH

[Nielsz]

vreemd dat er een verschil is tussen een HR en een VHR

[oh,when?]

Op dinsdag 12 februari 2002 14:32 schreef Nielsz het volgende:
vreemd dat er een verschil is tussen een HR en een VHR

een hoofdredacteur krijgt meer betaald

[Verwijderd]

Op dinsdag 12 februari 2002 14:32 schreef Nielsz het volgende:
vreemd dat er een verschil is tussen een HR en een VHR

Ik denk dat dat de oplossing is die ik al eerder had aangegeven nl. een noodoplossing. Ik stelde voor om het dan doen met de invoering van een code waarbij priviliges tijdelijk verhoogd werden.

In oh,when's geval gebruikt men geen codes, maar neemt de zegmaar, editor zelf publisher rechten indien nodig

ik zie dat ik telkens Que heb gebruikt ipv Queue

[Verwijderd]

Op dinsdag 12 februari 2002 14:42 schreef Gordijnstok het volgende:

ik zie dat ik telkens Que heb gebruikt ipv Queue

ik heb dat gewoon overgenomen

[Nielsz]

Op dinsdag 12 februari 2002 14:49 schreef sjako het volgende:

[..]

ik heb dat gewoon overgenomen

Jah ik heb het ook gewoon overgenomen jah

[Nielsz]

Ik zat eens te denken, jaja en wat als je nou de affiniteit met een type aangeeft per gebruiker?
Dus:
* floris - tweakdsl - 10
* femme - tweakdsl - 9
* daniel - tweakdsl - 8

Hij gaat dus eerst naar floris, dan femme en daarna daniel.

Die 'Tweakdsl' moeten natuurlijk wel in een andere tabel staan dan

[Verwijderd]

Op dinsdag 12 februari 2002 11:15 schreef Gordijnstok het volgende:
Ik ben momenteel bezig met het verder uitontwikkelen van een roll based systeem, waarbij er user roles zijn als author, editor, en publisher.
Er bestaat de mogelijkheid om acties van een user role eerst te laten controleren door een hoger persoon "in rang". Zo zal bijvoorbeeld de author een artikel schrijven, deze vervolgens in een wachtrij voor authorization zetten waarna de gemachtigde persoon het artikel kan controleren, en vervolgens live kan plaatsen, hetzij nogmaals doorsturen aan een nog hoger persoon "in rang". Met andere woorden er wordt een workflow gecreerd.

Die 'hogere rang' is een andere role neem ik aan?

Nu zit hem het dilemma bij de authorization. Ik kan per account in een extra column van de database het ID van de persoon aan wie toestemming gevraagd moet worden, toevoegen. Maar wat als deze persoon geen toestemming kan geven als deze ziek is, of een vrije dag heeft? Dan zal de que van deze persoon vollopen en het artikel blijven hangen. Niet echt efficient dus, zeker niet bij content wijzigingen met spoed.

Niet in databases denken. Roles zijn in feite een groep rechten met een naam. Elk systeem werkt echter met gebruikers, individuen. Je moet het dan ook vanuit het individu bekijken. Een individu logt in en door dat inloggen geeft het systeem hem een aantal rechten die vooraf zijn bepaald. Je zou hiervoor roles kunnen gebruiken, maar dat hoeft niet, je kunt ook ieder individu losse rechten geven, of een group based systeem gebruiken, komt allemaal op hetzelfde neer.

Wat het idee van roles anders maakt dan het idee van groups is dat het voor een leek makkelijker te begrijpen is als een user impersonates naar een andere role (dus neemt een andere role aan). Dus, 'gedraagt zich als manager' bv. In groupbased security heb je dat niet: een user is ingedeeld in een of meerdere groups en die groups hebben rechten toebedeeld gekregen. De user erft de rechten van die groups en that's it. Wil hij andere rechten, dan moet hij echt als iemand anders inloggen.

Workflow met meerdere lagen is altijd vol met valkuilen: zodra er authorisatie nodig is voor het tot een goed einde brengen van een traject, kan dat traject stagneren als die authorisatie niet komt. Ons ambtenaren apparaat is een goed voorbeeld . Omdat roles de mogelijkheid geven te 'impersonaten' (doen alsof je de manager bent), zou je het systeem kunnen uitbreiden met een impersonate functionaliteit, waarbij je als individu je kunt gedragen als iemand anders, maar je BLIJFT WEL dat individu. (Dus, pietje logt in, krijgt door impersonisation er extra rechten bij en doet iets, sluit dan de impersonisation af en heeft weer zn oude rechten, maar blijft t.a.t. pietje).

Echter, het kunnen impersonaten naar een andere role is al genoeg voor het ondermijnen van je structuur, dus dat zou alleen moeten kunnen indien een ander (3e persoon) die mogelijkheid openstelt. Bv een afdelingshoofd die weer boven de manager staat.

Je ziet, hoe meer lagen, hoe meer bureaucratie en hoe meer ellende.

Nu zou je zeggen, iedereen met een hogere rang dan de author mag authorizen. Waar ik dan bang voor ben, is dat het tevens niet efficient meer zal zijn. Authorizing loopt langs elkaar heen, en workflow loopt ipv lineair kriskras door elkaar heen.

workflow heeft niets met authorisatie te maken. workflow is het traject dat wordt afgelegd door een item. Dat traject is onderverdeeld in fases en het item kan van fase N naar fase N+1 indien is voldaan aan een aantal voorwaarden. In jouw geval bv dat het geauthoriseerd is door een of meerdere personen. Wie dat zijn duidt je aan dmv rechten (bijvoorbeeld). Wil je niet dat je item stokt in het traject, dan moet je ervoor zorgen dat de overgangen van de fases t.a.t. flexibel verlopen en de eisen voor een overgang t.a.t. snel kunnen worden ingewilligd. _DAT_ moet je oplossen.

Het is weer een stap terug, maar daardoor zie je wellicht hoe je het moet invullen. Bijvoorbeeld door de mogelijkheid te bieden dat men zich in een andere rol kan verheffen op bepaalde tijden, of onder bepaalde voorwaarden. Maar wellicht zie je zelf nu andere mogelijkheden. Niet in databasekolommen denken want dan kom je er niet uit.

[Verwijderd]

Op dinsdag 12 februari 2002 12:36 schreef Gordijnstok het volgende:
[..]
Ja dat klopt. In mijn visie is een publisher iemand die weet wat hij doet, en kan omgaan met de verantwoordelijkheden die daarbij horen. Als ik namelijk nog meer publishers ga koppelen aan een author kom ik in een visieuze cirkel terecht waarbij het mogelijk is dat alle publishers gekoppeld aan de author ziek zijn, afspraken hebben, kortom niet kunnen authorizen.

Val niet in de kuil van de 'Complexe Oplossing': hoe complexer de oplossing, hoe minder effectief deze is. Als het een kluwen van rechten en lagen wordt, zijn mensen snel geneigd 1 root account aan te maken die alles kan en iedereen logt in als dat account.

Je ontkomt niet aan het feit dat wanneer je PER SE authorisatie vereist voor een overgang van fase N naar fase N+1 en er is NIEMAND die die eis in kan willigen, je in een deadlock valt. Dit kun je alleen oplossen door dan TOCH iemand die authorisatie maar te laten doen, maar 1) waarom had je die eis dan als het toch kan worden omzeild en 2) als iemand het toch kon, had je geen deadlock.

M.a.w.: het is een situatie waarin de workflow stagneert, maar dat is inherent aan het fenomeen workflow: als een manager iets moet goedkeuren, want dat is zo gesteld, kun je daar niet vanaf wijken anders kun je net zo goed die eis laten vallen, immers uitzonderingen ondermijnen zo'n regel's effectiviteit in een organisatie.

Dus: wil je zo'n workflow, dan stagneert de boel soms. En dat is het nadeel van zo'n workflow. Organisaties die zo'n workflow vereisen vooraf, omzeilen deze later toch, om dit soort situaties te voorkomen. Hetgeen wat ik hierboven zei: de Complexe Oplossing faalt, en men logt in gevallen van deadlock in als de manager, doet dingen die men eigenlijk niet mag en het werk wordt toch gedaan. Goede zaak? Nee natuurlijk niet. Het laat wel zien dat in veel gevallen een meerlagen authorisatie onnodig is, bureaucratische rompslomp creeert en de efficiency van de digitalisering van de informatiestromen teniet doet. TENZIJ je dat maar voor lief neemt, omdat je per se wilt dat t.a.t. die workflow in stand blijft. Maar dan moet je daar ook voor 100% achter staan en het omzeilen onmogelijk maken als organisatie.

Soortgelijke voorbeelden zie je bij grote bedrijven en de chain-of-command mbt netwerkaccess en wat men mag op de desktop pc's: men mag niks, maar men heeft stiekum toch het admin password van het local domain wel achterhaald via een bevriende sysadmin, waardoor al die regeltjes teniet worden gedaan.

Voor een transparante werkomgeving als het web, weet de author niet dat de publisher er niet is. Dit krijgt hij niet te zien, hij krijgt ook de que niet te zien.

Goede zaak, het is nl. de author's pakkie-an niet HOE het item van fase veranderd.

Als ik nu als poster een bericht post op T.net, weet ik niet of zeg maar Floris aanwezig is om toestemming te verlenen, dus zie ik geen problemen met een overrun van de public que.

De author is daar ook nooit de schuldige van. Degene(n) die de eisen moeten inwilligen om een item (in dit geval een newsitem) van fase N (de author fase hier) naar fase N+1 (de gepubliceerde fase) te laten overgaan. Als je niet nadenkt over _WAAROM_ eisen zijn gesteld aan die overgang en _OF_ je het voor lief neemt dat er stagnatie op kan treden (als je dat niet doet hebben die eisen _GEEN ZIN_!) kom je er nooit uit. Workflow is een star iets wat dicipline vereist vwb de handhaving van het pakket eisen voor elke fase. Omdat dat pakket eisen er ligt weet je waarom dat zo is en houd je je eraan. Doe je dat niet, dan is het zinloos een workflow te implementeren, echt waar.

[Verwijderd]

Op dinsdag 12 februari 2002 12:21 schreef Wouter Tinus het volgende:
De DSP van Tweakers.net is ook voorzien van een uitgebreid rechtensysteem. Per account zijn er een stuk of 30 eigenschappen die ingesteld kunnen worden, helaas werkt het (nog) niet met groepen. Mijn advies: ZEKER DOEN, anders raak je het overzicht snel kwijt.

Per user kan bijvoorbeeld ingesteld worden of hij zijn werk zelf op de frontpage mag zetten, of hij werk van anderen mag aanpassen en of hij werk van anderen mag verwijderen. Bovendien kan gekozen worden of iemand nieuws mag doen, of reviews, of frontpage etc. etc. etc.

Die 30 eigenschappen zijn die deel van het recht wat de gebruiker heeft per afdeling (hardware/software), of is dit inclusief de afdelingen?..

ik kom nu namelijk qua rules in een policy pas op:
view/add/edit/delete/supervise/publish/schedule

[Nielsz]

Op vrijdag 15 februari 2002 09:23 schreef Gordijnstok het volgende:

[..]

Die 30 eigenschappen zijn die deel van het recht wat de gebruiker heeft per afdeling (hardware/software), of is dit inclusief de afdelingen?..

ik kom nu namelijk qua rules in een policy pas op:
view/add/edit/delete/supervise/publish/schedule

Ik gok inclusief..
Ik denk dat er ook de 'normale' rechten van t.net in zit. Dus ook reactie-edit, poll-management en ga zo maar door.

[Verwijderd]

Op vrijdag 15 februari 2002 09:23 schreef Gordijnstok het volgende:
[..]
Die 30 eigenschappen zijn die deel van het recht wat de gebruiker heeft per afdeling (hardware/software), of is dit inclusief de afdelingen?..

Ik denk de verschillende combinaties itemtype - recht. Als ik kijk naar een willekeurige site gemaakt met mn eigen CMS en die site heeft bv 50 verschillende itemtypes, dan heb ik per itemtype 5 rechten te verdelen.

ik kom nu namelijk qua rules in een policy pas op:
view/add/edit/delete/supervise/publish/schedule

Aan de hand van deze discussie heb ik de workflow en rechtensetje van mn CMS ook maar weer eens onder de loep genomen, en die view had ik niet, maar is idd wel handig (voor bv items die nog niet zijn gepublished, maar die dus wel verborgen moeten blijven voor mensen die geen view/edit/whatever recht hebben.)

Overigens is '(pre)view' iets wat je altijd samen met andere rechten gebruikt: edit -> preview, publish -> preview, delete -> preview, etc. in feite moet je altijd het item kunnen bekijken waar je acties op pleegt.

Ik heb overigens ook nog 'archive', want je wilt niet iedereen het recht geven items te archiveren.

[Verwijderd]

Op vrijdag 15 februari 2002 09:41 schreef Otis het volgende:

[..]

Ik denk de verschillende combinaties itemtype - recht. Als ik kijk naar een willekeurige site gemaakt met mn eigen CMS en die site heeft bv 50 verschillende itemtypes, dan heb ik per itemtype 5 rechten te verdelen.
[..]

Aan de hand van deze discussie heb ik de workflow en rechtensetje van mn CMS ook maar weer eens onder de loep genomen, en die view had ik niet, maar is idd wel handig (voor bv items die nog niet zijn gepublished, maar die dus wel verborgen moeten blijven voor mensen die geen view/edit/whatever recht hebben.)

Overigens is '(pre)view' iets wat je altijd samen met andere rechten gebruikt: edit -> preview, publish -> preview, delete -> preview, etc. in feite moet je altijd het item kunnen bekijken waar je acties op pleegt.

Ik heb overigens ook nog 'archive', want je wilt niet iedereen het recht geven items te archiveren.

Overigens komt mijn totaal nu momenteel op:

View: Alleen bekijken van eigen elementen
Create: Aanmaken van nieuwe elementen welke door de auteur zelf gemaakt zijn.
Edit: Wijzigen van elementen welke door de auteur zelf gemaakt zijn.
Remove: Verwijderen van elementen welke door de auteur zelf gemaakt zijn.
View_Global: Alleen bekijken van alle elementen ongeacht auteur
Edit_Global: Wijzigen van elementen ongeacht de auteur.
Remove_Global: Verwijderen van elementen ongeacht de auteur.
Supervise: Is gebruiker gemachtigd om te evalueren?.
Publisher: Mag gebruiker publishen?.
Schedule: Schedule toegang? In principe altijd op TRUE als Publisher ook TRUE is, alleen voor evt. later toch apart gedefinieerd.

Alle rechten zijn van het type boolean.

Archiveren heb ik er nog niet inzitten. In principe hoef je ook niet alles te archiveren. Wat buiten de output recordset valt is automatisch archief op de frontend. Er wordt dan gesorteerd op een date- en timestamp en versienummer van het element.

Speciale rechten zijn apart ondergebracht. Deze zijn namelijk niet inherent aan de unit roles.

Recovery Account: Alles wat de root ook kan + rechtstreekse DB toegang via een Database Grid.
Root Administrator: Totale toegang behalve rechtstreekse DB toegang. Wijzigen van security settings, encryptie-certificaten, ip-locking etc.
System Administrator: Gebruikers beheer behalve voor de gebruikers met Administrator status.

[Verwijderd]

Op vrijdag 15 februari 2002 10:01 schreef Gordijnstok het volgende:
[..]
Overigens komt mijn totaal nu momenteel op:
View: Alleen bekijken van eigen elementen
Create: Aanmaken van nieuwe elementen welke door de auteur zelf gemaakt zijn.
Edit: Wijzigen van elementen welke door de auteur zelf gemaakt zijn.
Remove: Verwijderen van elementen welke door de auteur zelf gemaakt zijn.
View_Global: Alleen bekijken van alle elementen ongeacht auteur
Edit_Global: Wijzigen van elementen ongeacht de auteur.
Remove_Global: Verwijderen van elementen ongeacht de auteur.
Supervise: Is gebruiker gemachtigd om te evalueren?.
Publisher: Mag gebruiker publishen?.
Schedule: Schedule toegang? In principe altijd op TRUE als Publisher ook TRUE is, alleen voor evt. later toch apart gedefinieerd.

Jij hebt duidelijk 'functionele rechten', dus rechten die los van waar ze op van toepassing zijn worden uitgevoerd, toch een iewat andere benadering (maar daarom niet slecht ).

Die supervise begrijp ik nog niet echt, want die moet ook editen neem ik aan?

Ik weet niet of je onderscheidt maakt tussen de verschillende elements (of items) waarmee de users werken. Indien je dat wel doet, bv page-templates, zou je rechten op die verschillende page templates kunnen defineren. een setje pagetemplates-rechten combinaties is dan een 'role', bv 'newseditor/publisher', waarbij aan alle newspage templates de edit/publish rechten zijn gegeven. Die role geef je dan aan users. Je kunt dan die global rechten schrappen.

Alle rechten zijn van het type boolean.
Archiveren heb ik er nog niet inzitten. In principe hoef je ook niet alles te archiveren. Wat buiten de output recordset valt is automatisch archief op de frontend. Er wordt dan gesorteerd op een date- en timestamp en versienummer van het element.

Jij hebt geen mogelijkheid dat je data op meerdere pages bv kunt laten zien, of dat je speciale archief pages hebt (of beter: een page met data wordt archiefpage, de huidige page wordt vervangen door een zelfde page maar met nieuwe data). ?

[Verwijderd]

Ik heb momenteel voor het rechtensysteem het volgende dbmodel om het uit te leggen.

table: units
id (auto-increment)
label (naam vd unit bv. software/hardware)

table: unit_roles
id (auto-increment)
unit (integer, gekoppeld aan units.id)
policy (integer, gekoppeld aan policies.id)
label (naam vd policy bv. Policy voor Authors)
description (korte uitleg over de role)

table: policies
id (auto-increment)
label (korte uitleg over de policy)
view (boolean)
edit (boolea)
etc.
etc.
etc.

table: user
id (auto-increment)
username
password
firstname
lastname
etc.
etc.

table: user roles
id (auto-increment)
user (integer, gekoppeld aan user.id)
unit role (integer, gekoppeld unit_roles.id)
supervisor (integer, gekoppeld aan user.id, wie is de supervisor van deze gebruiker?)
custompolicy [integer, gekoppeld aan policies.id voor een eigen policy ipv de policy vd unit role)

Een user is gekoppeld aan een rol. Deze rol kan bijv. Author, Editor, Publisher zijn. Deze rollen worden specifiek per unit gezet. Een user kan indien van toepassing in meerdere units een rol uitvoeren, waarbij per unit de user maximaal 1 rol kan uitvoeren.

De user kan een directe wijziging in rechten en regels per unit krijgen op 2 manieren nl:

1) Omzetten van de unit roll van de gebruiker
2) Toewijzen van een custompolicy op de user per unit

De user kan een indirecte wijziging in rechten en regels krijgen per unit op 3 manieren nl.

1) Omzetten van de policy van de unit role (dit zal tevens alle gebruikers binnen de groep beinvloeden, tenzij deze een custompolicy bezitten)
2) Door wijzigingen in de policy van een unit role
3) Door non-actief stellen van een unitrole of policy, waardoor een plaatsvervangende policy/unit role zal moeten worden geselecteerd..

[Verwijderd]

Overigens had ik er ook voor kunnen kiezen om lists te gebruiken. Want op deze manier wordt de user_roles table maximaal users*units records lang. De unit_roles tabel is ook echt bedoeld als koppelingstabel om rechten en users gescheiden te houden en op die manier schaalbaar en uitbreidbaar te houden.

Alleen heb ik een afkeer van columns waarbij koppelingen met andere tables op de interger,integer,integer manier worden gemaakt. Bovendien mag de SQL Server het query werk gaan doen, en worden recordsets netjes gecached binnen een timespan.

Als ik nu die gecachede recordset weer uit elkaar moeten pluizen omdat er lists in voor komen, dan ben ik stukken sneller af door gebruik te maken van veel records.