Hulp gezocht bij maken van kruistabel

Thomas Thanks.....,

thnx dit is in 1x goed... knap hoor. Voor de die hards zal die gesneden kost zijn, maar ik probeer het nog te bevatten wat er in de codering gebeurt :=)

Het resultaat is wat ik aanvankelijk voor ogen had... zie hier het resultaat...




Voor nu een werkbare situatie. Maar nu durf ik het eigenlijk niet te vragen. Maar wat zou er nog moeten gebeuren om dit interactief te maken. Hoe mooi en waardevol zo dat zijn? Wat ik bedoel is dat wanneer er nu bijvoorbeeld op een match (?) klikt er een opdracht in een tabel wordt weggeschreven voor intrekking van de toegekende rol... en wanneer op een lege cel (of symbool in dat veld) en in een tabel de rol wordt toegekend. Zodat mbv dit overzicht een controle kan uitvoeren met daarin mogelijke mutaties kan wegschrijven..

Misschien een wat veeleisende wens... maar ik ben benieuwd wat hiervoor gedaan moet worden. Ik overzie dit (nog) niet.

Nogmaals een dankjewel die me aangespoord hebben om door te gaan met de gegeven voorstellen en gewoon moet proberen... en natuurlijk diegene die de aanvullingen hebben toegelicht...

Keep Up The Good Work

Je bedoelt dat je de rechten zelf kan instellen, met een Ja of Nee (of eventueel blanco als rechten kunnen overerven)

Zoiets als dit?
[img]https://i.ibb.co/2kpQgg3/afbeelding.png[/img]

Gewoon elke <td> vullen met een <input type="checkbox">, met indien isset($draai[$key][$naam])) nog een checked attribuut. Alles in een <form> plaatsen en in een submit afhandelen (alles wissen en opnieuw schrijven), of nog mooier: onclick een asynchrone call en dat ene recht aanpassen (gezien het voorgaande zou ik met een <form>+submit beginnen ;-) ).

zo ongeveer bedoel inderdaad.

Bijvooreeld...
in dit overzicht zie je of iemand een rol heeft toebedeeld. Deze zou wanneer dit niet meer noodzakelijk is ingetrokken moeten worden. Een ander heeft bijvoorbeeld een rol niet terwijl hij deze wel zou moeten hebben. Dan zou je deze rol moeten toekennen. Deze mutaties zouden dan weggeschreven moeten worden in tabel bijvoorbeeld.

Maar wanneer ik de image zo bekijk dan lijkt het er wel wat op. Kan het niet goed beoordelen

Hmm. Allereerst, voor de beeldvorming. Is deze kruistabel een soort van "proof of concept" die aantoont wat de mogelijkheden zijn om al die data om te vormen naar een soort van webapplicatie?

Realiseer je ook dat aangezien je waarschijnlijk nog imports draait, elke wijziging die je in de database doet weer ongedaan wordt gemaakt bij een volgende import omdat die informatie niet "leidend" is.

Dat gezegd hebbende, als je dan op een gegeven moment de overstap maakt waarbij je de informatie in de database "leidend" laat zijn dan moet je ook zorgen dat dit 100% als een zonnetje draait, klopt, en (nagenoeg) geen fouten bevat.

Om dit te garanderen is het waarschijnlijk echt zaak om de boel ook te onderwerpen aan een zekere transformatie bij de import en dit in een heel erg strak database-ontwerp te gieten. Ik snap dat dit nu mogelijk nog niet aan de orde is, maar dit maakt zoveel dingen vele malen makkelijker, efficiënter en minder foutgevoelig.

Bijvoorbeeld, als ik mij niet vergis, op dit moment hangen de tabellen idm_role en idm_person2role echt aan elkaar op grond van de naam van de rol. Hier kun je uiteraard efficiënt queries op draaien door in beide tabellen hier een index op aan te brengen (of nog beter PRIMARY en FOREIGN KEYS), maar dit is (natuurlijk?) niet echt optimaal. Het zou misschien handiger zijn dat je voor de koppelingen tussen tabellen echt INT(egers) gebruikt, die een soort van intern identificatienummer voor een rol vormen. Bijkomend voordeel hiervan is dat de rolnaam niet langer "hard coded" in de database staat, en daarmee vrij veranderd mag worden. Immers, alle associaties met deze rol verlopen via het interne identificatienummer. Je zou de oorspronkelijke rolnaam nog in een apart veld kunnen opslaan, als een soort van vermelding naar de oude situatie. Daarbij zou je ook nog kunnen denken aan een veld voor een voor mensen beter leesbare naamgeving van de rol, ik vind ROLE:OU:40000001:ALGEMEEN nou niet bepaald leesbaar.

Ook zou je zeer serieus moeten overwegen om van dit ding een echte relationele database te maken, of misschien is deze database dat al? Welke tabeltypen (database-engine) gebruik je? MyISAM of InnoDB? Idealiter gebruik je InnoDB, want deze zijn bij uitstek geschikt voor dit soort administratieve systemen.

InnoDB ondersteunt o.a. FOREIGN KEY verwijzingen en database-transacties. Dit laatste is weer belangrijk als je op een juiste manier batches van gegevens wilt verwerken waarbij deze hele batch ofwel in het geheel, ofwel in het geheel niet uitgevoerd wordt als er onverhoopt iets fout gaat en niet half zodat de administratie van het systeem in de war loopt. Dit draagt dan weer bij aan de referentiële integriteit van de data in je systeem, en garandeert daarmee min of meer dat de onderlinge verbanden blijven kloppen.

Ook kun je regels opstellen waarbij tabellen opgeschoond kunnen worden (ON DELETE). Bijvoorbeeld, als jij een rol verwijdert dat dan ook 1x (zonder een extra query) de gebruiker-rol-koppeltabel wordt ontdaan van deze verwijderde rol.

Anyhow, ik denk dat het fijn is dat je nu iets werkends hebt, maar je kunt nog véééééééééééél meer winst pakken als je dingen bij de import platslaat in een nieuw(er) MySQL database-format.

Denk er eens over na.

---

En om antwoord te geven op je laatste vraag: ik denk dat het het "makkelijkste" is om een soort van constructie met AJAX-calls te maken waarbij, als je op een cel klikt, dat je daarmee direct een rol aan of uit kunt zetten. Dit in tegenstelling tot een soort van monsterformuler waarbij je alle rollen + gebruikers post en je dan alles moet updaten ofzo. Je hebt dan dus een soort van actie nodig die het gebruikers-id meegeeft, de rol (en hierbij is het dus weer handig dat je je in beide gevallen bedient van een intern id ter identificatie van zowel de gebruiker als de rol) en of deze aan of uitgezet dient te worden. De cel zelf kun je dan na succesvolle update voorzien van een pictogram voor "aan" of "uit" ofzo. De AJAX-call zal in zijn eenvoudigste vorm zoiets zijn als code.php?action=ajaxChangeUserRole&user=1&role=2&toggle=on/off o.i.d.. Uiteraard moet dit zelf ook weer een afgeschermde actie zijn (op zijn beurt ook weer beschermd worden met rollen/rechten).

En dan moet je mogelijk nog rekening houden met het feit dat meerdere mensen tegelijkertijd in dit paneel zitten te werken, deze zien dan mogelijk verschillende informatie. Als gebruiker A Pietje recht #1 geeft dan zal gebruiker B dat niet direct zien tenzij je hier voorzieningen voor treft of gebruiker B de pagina van het overzicht ververst.

Eigenlijk doe ik haast hetzelfde wat Rob zegt. Je maakt zelf een multi-dimensionale array aan, die je na het versturen met foreach doorwandelt, en alles netjes invoegt of updated:

In mijn geval is het dan dit. News is de module waar de rechten over gaan, en edit is de actie. De gebruikersgroep-ID geef ik in de GET-parameter aan.

<select name="rights[news][edit]">
	<option value="">-</option>
	<option value="1" checked>Ja</option>
	<option value="0">Nee</option>
</select>

@Thomas:

Hoe graag Dirk zou willen, als ik zijn eerdere post lees, kan hij weinig invloed uitoefenen op de opzet van de database. Als er een beetje structuur in de namen van de rollen zit, dan kan je met een array daar wel een filter overheen leggen zodat je die cryptische codes uit je view kan verwijdern en de rol kan herschrijven naar wat leesbaarders zoals bijv.: 'Computer Administratie'

Over monsterlijke formulieren gesproken die uiteindelijk honderden invulvelden vormen: Dat kan je ook platslaan met groepen die overerven. In mijn geval (zie afbeelding) vul je voor de rechtengroep alleen de velden in van belang zijn. overerving doet de rest. Lekker minimalistisch en weinig werk.

Ik geef wel toe dat het weer een uitdaging vormt als je rechtenconflicten uit de weg wilt gaan met een gebruiker die verschillende rechtengroepen heeft. Ik heb ooit eens bij de heren van Tweakers geïnformeerd die dit in hun forumsoftware* hebben, hoe hun dat deden, en het is best complex konden ze vertellen. maar het komt neer op:

- "positive inherit" dus als in de net bekeken groep een 'allowed' wordt uitgerekend, dan is dat vanaf nu de keuze
- "negative inherit" zelfde als voorgaande, maar dan met denied
- "overwrite" als er nu een beslissing is geldt ie altijd
- "ignore" alleen deze beslissing gebruiken als er nog geen eerdere keuze was gemaakt
- "clear" gooi de oude beslissing weg, zelfs als er in deze groep geen nieuwe is gemaakt (niet handig, dit zou het nutteloos maken om iemand in andere groepen te hebben)

[sub]* = Hun forumsoftware was vroeger door de makers (Parse) als closed-source ter download gezet onder de naam MyReact, met dit besproken rechtensysteem. Daar is ook mijn rechtensysteem van afgeleid in een wat simplistische opzet, en enkel met positive-inherit. Negative-inherit ga ik er nog eens bij bouwen.

Hier staat wat uitleg van de gearchiveerde documentatiepagina. De 'broken images' bij de overervingspagina is niets meer dan een 'yes' of 'no' of 'no-yes' plaatje als je de bron bekijkt.

De software al tijden niet meer ter download is en het bedrijf is ermee gestopt.[/sub]

="Thomas van den Heuvel op 20/08/2019 22:05:33"]
Hmm. Allereerst, voor de beeldvorming. Is deze kruistabel een soort van "proof of concept" die aantoont wat de mogelijkheden zijn om al die data om te vormen naar een soort van webapplicatie?

Voor de beeldvorming: dit kruistabel is bedoeld voor coordinatoren die moeten checken wie welke rol gekoppeld heeft en zou hier indien nodig wijzigingen op moeten kunnen doorvoeren. De oorspronkelijke data draait op een SAP omgeving waarvan wekelijks een import wordt gedaan op deze database. Deze methodiek zal niet veranderen omdat hier geen toestemming voor verleend zal worden. (Helaas).
Mutaties worden dus mbv Excelbestanden doorgevoerd. Wat ik nu dus bedoel is dat je mbv deze kruistabel een rol kan toekennen bij iemand die de rol nog niet heeft en intrekken bij degene die de rol teveel heeft of niet meer nodig heeft. Deze mutaties wil ik dan weg laten schrijven in een aparte (nog aan te maken) tabel op wekelijkse basis. Na verwerking in SAP kan er weer de nieuwe set van bestanden worden geimporteerd.

Deze methodiek is tot stand gekomen omdat de GUI van SAP heel erg summier is heel onoverzichtelijk is door statische kleine schermen te tonen. Iemand die daar dagelijks mee moet werken wordt daar als snel goed flauw van. Tot voor kort gebruikte ik een MS Acces database maar die kan zo langzamerhand niet meer met de hoeveelheid data overweg. Vandaar deze constructie.

Realiseer je ook dat aangezien je waarschijnlijk nog imports draait, elke wijziging die je in de database doet weer ongedaan wordt gemaakt bij een volgende import omdat die informatie niet "leidend" is.

Zoals hierboven al besproken deze database zal nooit en te nimmer in de lead komen en zal altijd ondergeschikt zijn aan die SAP variant.[/quote]

Dat gezegd hebbende, als je dan op een gegeven moment de overstap maakt waarbij je de informatie in de database "leidend" laat zijn dan moet je ook zorgen dat dit 100% als een zonnetje draait, klopt, en (nagenoeg) geen fouten bevat.

Zoals hierboven beschreven. Dit zal nooit gebeuren. (Was het maar zo)

)
t te garanderen is het waarschijnlijk echt zaak om de boel ook te onderwerpen aan een zekere transformatie bij de import en dit in een heel erg strak database-ontwerp te gieten. Ik snap dat dit nu mogelijk nog niet aan de orde is, maar dit maakt zoveel dingen vele malen makkelijker, efficiënter en minder foutgevoelig.

Begrijp wat je zegt maar ik zit vast aan de set vaste velden die worden gedumpt in totaal in 13 csv bestanden. Maar dat is dan ook set aan informatie die voor deze tabel niet uitmaken.

Bijvoorbeeld, als ik mij niet vergis, op dit moment hangen de tabellen idm_role en idm_person2role echt aan elkaar op grond van de naam van de rol. Hier kun je uiteraard efficiënt queries op draaien door in beide tabellen hier een index op aan te brengen (of nog beter PRIMARY en FOREIGN KEYS), maar dit is (natuurlijk?) niet echt optimaal. Het zou misschien handiger zijn dat je voor de koppelingen tussen tabellen echt INT(egers) gebruikt, die een soort van intern identificatienummer voor een rol vormen. Bijkomend voordeel hiervan is dat de rolnaam niet langer "hard coded" in de database staat, en daarmee vrij veranderd mag worden. Immers, alle associaties met deze rol verlopen via het interne identificatienummer. Je zou de oorspronkelijke rolnaam nog in een apart veld kunnen opslaan, als een soort van vermelding naar de oude situatie. Daarbij zou je ook nog kunnen denken aan een veld voor een voor mensen beter leesbare naamgeving van de rol, ik vind ROLE:OU:40000001:ALGEMEEN nou niet bepaald leesbaar.

Scherp opgevat dat de tabel een samenhang hebben op gronde van de naam van de rol en niet van een Id veld. Dit zou zeer zeker niet mijn keus zijn geweest maar zo is het in SAP in dit geval voor gekozen. Het is even niet anders. Toch is de rolnaam een uniek waarde. Deze kan je herleiden omdat ze allemaal beginnen met ROLE:<roltype?:* Ben het eens dat dan een rol genaamd ROLE:OU:40000001:ALGEMEEN nou niet bepaald leesbaar is. Maar er is een extra veld beschikbaar wat een display name bevat. Dit is wel een leesbare naam. Maar degene die hier dagelijks mee werken, werken liever met het unieke kenmerk veld. Vandaar dat ik die ook in de kruistabel gebruik. Maar indien gewenst kan dit aangepast.

Ook zou je zeer serieus moeten overwegen om van dit ding een echte relationele database te maken, of misschien is deze database dat al? Welke tabeltypen (database-engine) gebruik je? MyISAM of InnoDB? Idealiter gebruik je InnoDB, want deze zijn bij uitstek geschikt voor dit soort administratieve systemen.

Moest even zoeken.. Had het niet meteen door waar ik deze info zo snel weg moest halen maar de tabellen die ik gebruik heb zijn van type MyISAM. Eerlijkheidshalve moet ik toegeven dat ik niet weet wat het verschil is.

InnoDB ondersteunt o.a. FOREIGN KEY verwijzingen en database-transacties. Dit laatste is weer belangrijk als je op een juiste manier batches van gegevens wilt verwerken waarbij deze hele batch ofwel in het geheel, ofwel in het geheel niet uitgevoerd wordt als er onverhoopt iets fout gaat en niet half zodat de administratie van het systeem in de war loopt. Dit draagt dan weer bij aan de referentiële integriteit van de data in je systeem, en garandeert daarmee min of meer dat de onderlinge verbanden blijven kloppen.

Hier begin je me kwijt te raken en begrijp ik niet meer wat je me nu vertelt. Het lijkt me dat alleen de de gemuteerde waarden worden opgeslagen in een aparte tabel. Rolkoppelingen die ongemoeid zijn behoeven ook niet weer opnieuw te worden ingeladen. Daarmee zou ik de historie denk ik overschrijven.
[/quote]
Ook kun je regels opstellen waarbij tabellen opgeschoond kunnen worden (ON DELETE). Bijvoorbeeld, als jij een rol verwijdert dat dan ook 1x (zonder een extra query) de gebruiker-rol-koppeltabel wordt ontdaan van deze verwijderde rol.

Dit zou kunnen inderdaad maar is denk niet zinvol omdat de mutaties mbv een Excel bestand worden aangeboden en in SAP worden ingelezen en dan pas de mutatie daadwerkelijk worden doorgevoerd.

.w, ik denk dat het fijn is dat je nu iets werkends hebt, maar je kunt nog véééééééééééél meer winst pakken als je dingen bij de import platslaat in een nieuw(er) MySQL database-format.

Denk er eens over na.

Ik heb geen mogelijkheid om die gegevens die gedumpt worden te beïnvloeden. Die zijn van een bepaalde opmaak en is een gegeven.
[/quote]
---

En om antwoord te geven op je laatste vraag: ik denk dat het het "makkelijkste" is om een soort van constructie met AJAX-calls te maken waarbij, als je op een cel klikt, dat je daarmee direct een rol aan of uit kunt zetten. Dit in tegenstelling tot een soort van monsterformuler waarbij je alle rollen + gebruikers post en je dan alles moet updaten ofzo. Je hebt dan dus een soort van actie nodig die het gebruikers-id meegeeft, de rol (en hierbij is het dus weer handig dat je je in beide gevallen bedient van een intern id ter identificatie van zowel de gebruiker als de rol) en of deze aan of uitgezet dient te worden. De cel zelf kun je dan na succesvolle update voorzien van een pictogram voor "aan" of "uit" ofzo. De AJAX-call zal in zijn eenvoudigste vorm zoiets zijn als code.php?action=ajaxChangeUserRole&user=1&role=2&toggle=on/off o.i.d.. Uiteraard moet dit zelf ook weer een afgeschermde actie zijn (op zijn beurt ook weer beschermd worden met rollen/rechten).

Wat je me hier probeert te vertellen begrijp ik werkelijk waar geen hout van. AJAX heb ik alleen van gehoord en heb ik geen ervaring. Ben net goed en wel een beetje aan het loskomen in PHP en MySql... Onontgonnen gebied oftewel een zwart gat ;-))

n moet je mogelijk nog rekening houden met het feit dat meerdere mensen tegelijkertijd in dit paneel zitten te werken, deze zien dan mogelijk verschillende informatie. Als gebruiker A Pietje recht #1 geeft dan zal gebruiker B dat niet direct zien tenzij je hier voorzieningen voor treft of gebruiker B de pagina van het overzicht ververst.

Dit heb ik ondervangen. Er zit een login aan met daaraan rechten wat je wel / niet mag doen op gronde van je inlogId.

Je quote loopt niet echt lekker;-)

- Ariën - op 20/08/2019 23:12:33

Je quote loopt niet echt lekker;-)

Sorry, I know.... maar d'r ging van alles mis... lappen tekst verdwenen op moment wanneer ik op het tekstballonnetje klikt... excuus. MAar ik hoop dat de samenhang nog leesbaar / begrijpelijk is

Wat Thomas bedoelt is dat je de rechten met een enkele klik dan kan geven, in plaats van je wezenloos klikken in tientallen tot honderden select-boxen in een formulier. Met een klik op een recht voer je dan een AJAX-request uit die het recht instelt, en de stijl van de cel aanpast naar: "gekozen".

Snap je ;-)?

Maar als je met overerving werkt, en dat iemand meerdere rollen mag krijgen (administratie + financiële boekhouding inzien), dan schilt je dat een hoop rechten instellen omdat je enkel de nodige rechten instelt.

Verder vind ik het wel een beetje diep gaan, wat Thomas zegt, om iets in te bouwen om conflicten te vermijden als twee verschillende gebruikers op de rechten-bewerk-pagina verschillende rechten willen aanpassen. Doorgaans met een goede opbouw pas je minimale rechten, en hoe groot is de kans dat twee personen één iets aanpassen? Als je na afloop controleert of het klopt, dan zit je best safe.

Je kan van alles voorkomen, maar ik vind dat er gewoon grenzen zijn. Rechten aanpassen is niet triviaal. Een veiligheidsnet inbouwen kan altijd, maar je moet er wel bij stilstaan of het echt nodig is. Als er maar één iemand is die de rechten in de organisatie uitdeelt, dan kan je zeker zijn dat deze code onbelangrijk is. Inbouwen kan altijd....