Hulp gezocht bij maken van kruistabel
Pagina: « vorige 1 2 3 4 5 volgende »
Hoe ziet in korte lijnen je tabel eruit met minimalistische gegevens?
Enige wat ik mij kan indenken is een opbouwfout in je table.
Ik roep in mijn SELECT de rol vanuit de verkeerd tabel aan. In code hierboven riep ik de rol aan uit de tabel idm_role.MSKEYVALUE_ROL maar dit moest dus idm_person2role.MSKEYVALUE_ROL zijn.... Nu klopt het dus helemaal... Pfff.
Nu zou ik waarden van de rollen en rijen bij elkaar opgeteld willen hebben ... hoe moet ik dit aanvliegen?
Wat ik dus aanvullend zou willen dat er een optelling wordt gedaan van iedere kolom en van iedere rij... zodat je kan aflezen hoe vaak een rol gekoppeld is en hoeveel rollen een persoon heeft.
toch vind ik op forum niet zo gek veel voorbeelden hoe ik dat zou moeten doen. Als ik aan oom Google vraag wordt ik weer het hele internet overgestuurd met 1001 mogelijkheden waar geen hout van snap. Heb je iets meer houvast?
Voor de rechten maak je een apart array aan waarbij je per id elke keer 1 optelt (data2[<right id>]++), wel even initialiseren op 0 ingeval <right id> nog niet voorkomt in data2.
En als je dus deze arrays opbouwt voordat je de tabel genereert heb je dus ook meteen alle informatie beschikbaar.
stukje bij beetje en probeersel hier, probeersels daar kom ik dichterbij het resultaat waar ik naar op zoek ben.
mbv een COUNT kan ik het aantal rollen tellen die iemand heeft. Dat werkt. Zie afbeelding hieronder.
Echter de horizontale rij tellen dat lukt me niet. Van alles geprobeerd maar de methodiek nog niet gevonden. Met een count krijg ik wel het aantal medewerkers geteld, maar dat is niet wat ik zoek. Ik zou dus aan hoeveel medewerkers een rol is toegekend.
De afbeelding van de matrix zover ik hem nu gereed heb:
de code die ik hiervoor gebruik is:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
function ou_r2mkruistabel (){
global $connection;
$where = NULL;
if (isset($_GET['ou'])){
$where = 'WHERE idm_person.ACHMEA_REF_OU = "'.mysqli_real_escape_string($connection, $_GET['ou']).'"';
}
$sqlUitlezen = mysqli_query($connection, "SELECT
CONCAT(idm_person.ACHMEA_CALLNAME, ' ', idm_person.MX_LASTNAME, ' <br>(', idm_person.ACHMEA_EMPLOYEENUMBER, ')' ) naam,
idm_person2role.MSKEYVALUE_ROL rol
FROM `idm_person`
LEFT JOIN `idm_person2role`
ON idm_person.MSKEYVALUE_MEDEWERKER = idm_person2role.MSKEYVALUE_MEDEWERKER
LEFT JOIN `idm_role`
ON idm_role.MSKEYVALUE_ROL = idm_person2role.MSKEYVALUE_ROL
".$where."
ORDER BY idm_person2role.MSKEYVALUE_ROL, idm_person.MX_LASTNAME ASC
");
//---------------
$sqlUitlezenOu = mysqli_query($connection, "SELECT
idm_person.DISPLAYNAME,
idm_ou.MSKEYVALUE_OU,
idm_ou.DISPLAYNAME
FROM idm_person
INNER JOIN `idm_ou` ON idm_person.ACHMEA_REF_OU = idm_ou.MSKEYVALUE_OU
".$where."
");
$sqlTelRecords = mysqli_num_rows($sqlUitlezen);
$sqlAantal = $sqlTelRecords - 1;
$sqlAantalOu = mysqli_num_rows($sqlUitlezenOu);
if ($sqlAantalOu > 0){
$sqlDataOu = mysqli_fetch_assoc($sqlUitlezenOu);
echo '<table border="0" width="100%">';
echo '<tr>';
echo '<td align="center" valign="top" rowspan="3" width="100"><a href="javascript:javascript:history.go(-1)"><img src="../img/vorige_pagina_button.png" height="80"></td>';
echo '<td valign="bottom"><h3>Rol / Medewerker koppelingen (matrix)</h3></td>';
echo '</tr>';
echo '<td valign="top"><h2>'.$sqlDataOu['DISPLAYNAME'].'</h2></td>';
echo '</tr>';
echo '<tr>';
echo '<td colpan="2" align="right"><h6>Ik heb '.$sqlAantal.' rol / medewerker koppelingen gevonden op de afdeling <i>'.$sqlDataOu['DISPLAYNAME'].'</i></h6></td>';
echo '</tr>';
echo '</table>';
}
//---------------
$sqlData = mysqli_fetch_all($sqlUitlezen, MYSQLI_ASSOC);
if ($sqlAantal > 0){
foreach($sqlData as $rij) {
$namen[$rij['rol']] = $rij['rol'];
$draai[$rij['naam']][$rij['rol']] = true;
}
echo '<table id="idmdata" border="1">' . PHP_EOL;
echo '<tr>
<th colspan="2"></th>';
foreach($draai as $key=>$rol) {
echo '<th>' . $key . '</th>';
}
echo '</tr>';
echo '<tr>
<td>Uniek kenmerk rol</td>
<td>#</td>';
foreach($draai as $key=>$rol) {
echo '<td align="center"><font size="2"><b><i>'.count($rol).'</i></b></font></td>';
}
echo '</tr>';
foreach ($namen as $naam) {
echo '<tr>
<td>'. $naam . '</td>' . PHP_EOL;
echo '<td>'.count($draai).'</td>';
foreach($draai as $key=>$rol) {
if(isset($draai[$key][$naam])) {
echo '<td align="center"><b>?</b></td>';
}else{
echo '<td></td>';
}
}
echo '</tr>';
}
echo '</table>';
}else{
echo '<center><a href="javascript:javascript:history.go(-1)"><img src="../img/no-data.png"></a></center>';
}
}
global $connection;
$where = NULL;
if (isset($_GET['ou'])){
$where = 'WHERE idm_person.ACHMEA_REF_OU = "'.mysqli_real_escape_string($connection, $_GET['ou']).'"';
}
$sqlUitlezen = mysqli_query($connection, "SELECT
CONCAT(idm_person.ACHMEA_CALLNAME, ' ', idm_person.MX_LASTNAME, ' <br>(', idm_person.ACHMEA_EMPLOYEENUMBER, ')' ) naam,
idm_person2role.MSKEYVALUE_ROL rol
FROM `idm_person`
LEFT JOIN `idm_person2role`
ON idm_person.MSKEYVALUE_MEDEWERKER = idm_person2role.MSKEYVALUE_MEDEWERKER
LEFT JOIN `idm_role`
ON idm_role.MSKEYVALUE_ROL = idm_person2role.MSKEYVALUE_ROL
".$where."
ORDER BY idm_person2role.MSKEYVALUE_ROL, idm_person.MX_LASTNAME ASC
");
//---------------
$sqlUitlezenOu = mysqli_query($connection, "SELECT
idm_person.DISPLAYNAME,
idm_ou.MSKEYVALUE_OU,
idm_ou.DISPLAYNAME
FROM idm_person
INNER JOIN `idm_ou` ON idm_person.ACHMEA_REF_OU = idm_ou.MSKEYVALUE_OU
".$where."
");
$sqlTelRecords = mysqli_num_rows($sqlUitlezen);
$sqlAantal = $sqlTelRecords - 1;
$sqlAantalOu = mysqli_num_rows($sqlUitlezenOu);
if ($sqlAantalOu > 0){
$sqlDataOu = mysqli_fetch_assoc($sqlUitlezenOu);
echo '<table border="0" width="100%">';
echo '<tr>';
echo '<td align="center" valign="top" rowspan="3" width="100"><a href="javascript:javascript:history.go(-1)"><img src="../img/vorige_pagina_button.png" height="80"></td>';
echo '<td valign="bottom"><h3>Rol / Medewerker koppelingen (matrix)</h3></td>';
echo '</tr>';
echo '<td valign="top"><h2>'.$sqlDataOu['DISPLAYNAME'].'</h2></td>';
echo '</tr>';
echo '<tr>';
echo '<td colpan="2" align="right"><h6>Ik heb '.$sqlAantal.' rol / medewerker koppelingen gevonden op de afdeling <i>'.$sqlDataOu['DISPLAYNAME'].'</i></h6></td>';
echo '</tr>';
echo '</table>';
}
//---------------
$sqlData = mysqli_fetch_all($sqlUitlezen, MYSQLI_ASSOC);
if ($sqlAantal > 0){
foreach($sqlData as $rij) {
$namen[$rij['rol']] = $rij['rol'];
$draai[$rij['naam']][$rij['rol']] = true;
}
echo '<table id="idmdata" border="1">' . PHP_EOL;
echo '<tr>
<th colspan="2"></th>';
foreach($draai as $key=>$rol) {
echo '<th>' . $key . '</th>';
}
echo '</tr>';
echo '<tr>
<td>Uniek kenmerk rol</td>
<td>#</td>';
foreach($draai as $key=>$rol) {
echo '<td align="center"><font size="2"><b><i>'.count($rol).'</i></b></font></td>';
}
echo '</tr>';
foreach ($namen as $naam) {
echo '<tr>
<td>'. $naam . '</td>' . PHP_EOL;
echo '<td>'.count($draai).'</td>';
foreach($draai as $key=>$rol) {
if(isset($draai[$key][$naam])) {
echo '<td align="center"><b>?</b></td>';
}else{
echo '<td></td>';
}
}
echo '</tr>';
}
echo '</table>';
}else{
echo '<center><a href="javascript:javascript:history.go(-1)"><img src="../img/no-data.png"></a></center>';
}
}
Hoe ga ik het nu voor elkaar krijgen dat het aantal rollen gekoppeld aan de hoeveelheid personen opgeteld worden?
Gewijzigd op 19/08/2019 21:05:03 door - DHU -
Dus zoiets (niet getest)?
Code (php)
En regel 88 wordt dan volgens mij $roleCount[$naam] in plaats van count($draai)?
Persoonlijk zou ik het genrereren van de gewenste data en het uitdraaien van de tabel wat meer scheiden, want op deze manier wordt het nogal snel onoverzichtelijk.
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
Zoiets als dit?
Gewijzigd op 20/08/2019 21:36:45 door - Ariën -
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
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
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.
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.
Code (php)
1
2
3
4
5
2
3
4
5
<select name="rights[news][edit]">
<option value="">-</option>
<option value="1" checked>Ja</option>
<option value="0">Nee</option>
</select>
<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:
Quote:
- "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)
- "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)
* = 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.
Gewijzigd op 20/08/2019 22:43:39 door - Ariën -
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?
Quote:
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.
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.
Quote:
)Zoals hierboven beschreven. Dit zal nooit gebeuren. (Was het maar zo)
t te garanderen is het
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
Dit heb ik ondervangen. Er zit een login aan met daaraan rechten wat je wel / niet mag doen op gronde van je inlogId.
- 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
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....
Gewijzigd op 20/08/2019 23:59:37 door - Ariën -
Pagina: « vorige 1 2 3 4 5 volgende »