jogosultság kezelés - sql
Sziasztok!
Egy sql alapú jogosultság kezelő rendszeren dolgozok, és kicsit elakadtam... A feladat leírása:
Felhasználói hieararchia kiépítése:
Csoportok, alcsoportok
Egy alcsoport tartozhat több csoporthoz, és egy csoportnak több alcsoportja lehet.
Pl.:stb...
Az azonos alcsoportoknak azonos jogaik vannak, de a főcsoport határozza meg, hogy melyik modult láthassa, vagy az adott modulon belül mit tehet, mit nem.
Ehhez még hozzá jön, hogy akár egyénenként is lehet jogokat adni, mert pl lehet, hogy az osztály1 vezetője más elfoglaltság miatt átadja a szerepét egy másik tagnak, vagy akár a másik osztály vezetőjének is.
Eddig nagyjából el is jutottam, hogy hogy építsem fel az adatbázist, viszont ahol elakadtam, hogy vannak menü pontok, és van olyan menü, aminek további almenüji is vannak...
Minden egyes menü, és almenü pont csatlakozik egy modulhoz, illetve a modul egy meghatározott részéhez.
Pl Admin modul:
- Saját adataink módosítása
- Új felhasználó hozzáadása
- Más felhasználó adatainak módosítása
- Hozzáférési jogok adása, módosítasa csoportoknál/alcsoportoknál
...
A modul egyes részeihez nem mindenkinek szabad hozzáférnie.
Itt akadtam el, hogy ebbe a modellbe hogy tudom beilleszteni a menüknek a kezelését, illetve abban, hogy hogy lehet megoldani, ha még nincs bejelentkezve felhasználó, mert egyes menüknek/moduloknak akkor is működnie kellene...
Itt egy kép ameddig eljutottam az adatbázis tervezésében.
Remélem sikerült érthetően leírnom... :) Előre is köszönöm a segítséget, ötleteket!
■ Egy sql alapú jogosultság kezelő rendszeren dolgozok, és kicsit elakadtam... A feladat leírása:
Felhasználói hieararchia kiépítése:
Csoportok, alcsoportok
Egy alcsoport tartozhat több csoporthoz, és egy csoportnak több alcsoportja lehet.
Pl.:
Cég
|
Felsővezető
| |
Osztály1 Osztály2
| |
Osztály vezető Osztály vezetőAz azonos alcsoportoknak azonos jogaik vannak, de a főcsoport határozza meg, hogy melyik modult láthassa, vagy az adott modulon belül mit tehet, mit nem.
Ehhez még hozzá jön, hogy akár egyénenként is lehet jogokat adni, mert pl lehet, hogy az osztály1 vezetője más elfoglaltság miatt átadja a szerepét egy másik tagnak, vagy akár a másik osztály vezetőjének is.
Eddig nagyjából el is jutottam, hogy hogy építsem fel az adatbázist, viszont ahol elakadtam, hogy vannak menü pontok, és van olyan menü, aminek további almenüji is vannak...
Minden egyes menü, és almenü pont csatlakozik egy modulhoz, illetve a modul egy meghatározott részéhez.
Pl Admin modul:
- Saját adataink módosítása
- Új felhasználó hozzáadása
- Más felhasználó adatainak módosítása
- Hozzáférési jogok adása, módosítasa csoportoknál/alcsoportoknál
...
A modul egyes részeihez nem mindenkinek szabad hozzáférnie.
Itt akadtam el, hogy ebbe a modellbe hogy tudom beilleszteni a menüknek a kezelését, illetve abban, hogy hogy lehet megoldani, ha még nincs bejelentkezve felhasználó, mert egyes menüknek/moduloknak akkor is működnie kellene...
Itt egy kép ameddig eljutottam az adatbázis tervezésében.
Remélem sikerült érthetően leírnom... :) Előre is köszönöm a segítséget, ötleteket!
Én azt tudom ajánlani, hogy
Acl
Ami a barátod lehet: acl, bitmask stb...
köszi átnézem ezeket is, bár
nézegettem a linket... de ez
A Drupal felhasználói és
modul nem kell adatbázisba
A usereknek egyénileg tárolod a jogait.
Az egyes modulok (vagy akár csak egy egy funkció) egyetlen fv hívással le tudja kérdezni, hogy adott (aktuális) user rendelkezik e xy joggal. Ha nem -》 hibát dob. Így a modulokat nem kell tárolni (persze lehet, ha mondjuk az is változhat, hogy adott feature hez milyen role kell).
Így a szükséges táblák:
Users, Roles, UsersRoles (*) (kapcsoló tábla), Groups, GroupsRoles (kapcsoló), UsersGroup.
* Azért hasznos, mert ugyan módosításkor kicsit több a matek (insert / update), de lekérdezéskor, ami sokkal gyakrabban van, csak 3 tábla lesz LEFT JOIN, nem 5.
Természetesen Groups lehet fa struktúra is, ha szükséges.
Remélem érthetően írtam le. :)
Köszönöm a választ! :) Még
-- Users:
- u_id
- u_login
- password
-- Roles
- r_id
- r_name
- r_role (pl jogosultsági szint)
-- UsersRoles
- ur_u_id (kapcsolódik a Users tábla u_id oszlopához)
- ur_r_id (kapcsolódik a Roles táblához)
- ur_g_id (kapcsolódik a Groups táblához)
-- Groups
- g_id
- g_name
-- GroupsRole
- gr_g_id (kapcsolódik a Groups táblához)
a többinél kicsit elakadtam... A UserGroup táblának mi a konkrét funkciója?
UserGroup
Menet:
- user t azt mondod, hogy legyen A és B csoport tagja.
- Beírod UsersGroup ba.
- GroupsRoles ből kikeresed, milyen Role ok vannak a csoportokban.
- Ezeket a User Id val be teszed UsersRoles ba.
Amikor a User jogai kellenek, elég csak a User, UsersRoles és Roles táblák join.
(Ami private kérdés volt, kérlek tedd fel itt, hogy ne csak én tudjak válaszolni)
Szerk.
UsersGroup akkor érdekes, ha egy Group változik, akkor ez alapján tudsz végig menni, hogy kiket kell update.
Rendben :)
a táblák részletei
tábla kapcsolatok
A kérdés az lenne, hogy hogy tudnék optimális csoport fát csinálni.
Ahogy ki kellene néznie pl:
Főcsoport: Munkavégzés helye
Alcsoport: Beosztás
Ami még fontos, hogy vannak olyan csoportok, amiknek nincs alcsoportja pl:
oldal tulajdonos
admin
illetve vannak olyan helyzetek mikor valaki több főcsoportba, vagy akár több alcsoportba is tartozhat. Pl helyettesítés, vagy több munkakörben való részvétel.
Hozzá kell tennem, hogy ebben a témában nagyon kezdő vagyok, így a tábla kapcsolatokat is főleg saját kútfőből állítottam össze...
eddig jó
Annyi kis kiegészítés, hogy érdemes következetesnek maradni kis és nagy betű és egyes és többes szám terén a nevekben.
A munkavégzés helye illetve beosztás nem hinném, hogy jogosultsági kérdés lenne.
Eredetileg cégen belüli osztályok és csoportok voltak, ezek vezetői, stb.
Ennek a hierarchiának a kitalálása a te feladatod, a cég vezetőivel egyeztetve. :)
Én nem ismerem a céget és az igényt.
Tetszőleges fa struktúra ki alakítható pl nested set megoldással, ehhez a Groups táblába kell még 2 integer oszlop. (Ha meg találom, linkelem)
Bármennyi csoportba tartozhat egy user, erre szolgál a UsersGroups tábla.
Arra érdemes figyelni, hogy ugyanazt a Role t ugyanazzal a userrel ne szúrd be többször a UsersRoles táblába.
Helyettesítés stb: admin hozzá adja azt a csoportot (Groups), majd mikor már nem kell, elveszi.
Hozzá kell tennem, hogy kezdőtől nagyon jó adatbázis tervet láttam. :)
szerk:
Nested tree
Köszönöm. :) Át is rágom
Egyébként melyik adatbázis kezelőt érdemesebb használni? Mert bár elterjedt a mysql, van aki mégis a postgresql-t ajánlja... Én eddig mysql-el dolgoztam, de csak nagyon alapszintű
adatbázis kezeléssel, alap táblakapcsolatokkal csak nem rég... Ilyen adatmodellezést meg csak 2-3 hete kezdtem el csinálni. Most feltettem a pgsql-t is. Az esetleges könnyebb váltás miatt már PDO-t használok.
db server
Egyes csomagok fizetősek, de ott van pl a MariaDB is, ami elvileg soha nem lesz fizetős. Mondjuk ezt amiatt nem javaslom, hogy sok mindent kérés nélkül kis betűsre alakít...
Annyi, hogy PHP alól ne használd az elavult mysql_ ... fv eket.
Helyette mysqli_ .
Átolvastam a linket... A
A munkavégzéssel kapcsolatban viszont nem fogalmaztam elég világosan, pontosabban rosszul. :) Ez egy szociális központ, ami több munkacsoportot ölel fel, és minden munkacsoportnak megvannak a maga alcsoportjai, vagyis beosztásai: csoportvezető, alkalmazottak (de az alkalmazottak csoportja is változó, mert van ahol sima beosztottak vannak csak, de van ahol további almunkacsoportok tartoznak egy vezető alá). Ezek a munka csoportok, egyrészt más más adatokat láthatnak, másrészt meg más más modulokat érhetnek el. Az általad linkelt fa szerkezet nagyon jó arra, hogy pl az egyes vezetők csak az alattuk lévő csoportba tartozók adatait láthassák. Bár sajnos a cikk nem folytatódott, pedig lényeges lenne a tábla kitöltése, mert pl egy új csoport felvétele, törlése, vagy épp áthelyezése megváltoztatja a fa kinézetét...
Túl bonyolítod
Viszont máris jócskán túl lőttünk a célon.
Felhasználó és jogosultság kezelés, ahonnan indultunk. Ezt kell jól megvalósítani, ne tágítsd tovább a scope ot.
Így is ez már túl sok lett: vagy arra van szükség, hogy egy user több group ba tartozhasson, vagy arra, hogy a group ok lehessenek parent - child viszonyban.
A kettő együtt biztosan felesleges.
Az, hogy később milyen láthatóság hogyan dől el, nem része ennek a feladatnak.
Mint mondtam, az pusztán role fv e lehet. Ez a háttér group dolog csak arra való, hogy könnyebben tudd kezelni a Role okat.
Admin felület pedig természetesen tudjon létrehozni Role is, Group is, stb, és minden fajta update is.
Szerk.:
Bocsi, Poetro cikke az igazán jó, itt van insert és update is. De a sorozatban te is megtaláltad volna. :)
igen ez igaz. :) Egyébként
Egyébként ebből gondoltam hogy folytatás lesz, és emiatt nem olvastam visszafele:
"Zárószó:
...
A hierarchia módosítása még érdekesebb és egyeben bonyolultabb feladat. Ha a téma érdekel, és lenne kedved továbbdolgozni, örömmel várnám a cikk IV. részét."
Ok, neked is van igazad,
Van további kérdésed, vagy boldogulsz?
Ha meg lesz a számodra megfelelő megoldás, én (is) szívesen látnám itt. (És gondolom sokan mások is.)
mindenképpen, ha összerakom,
Az sql amin elakadtam
LINE 1: SELECT node.g_id AS id, node.g_name AS name, COUNT(*) - 1 AS...
hűha
- ha egy dump letölthető lenne a jelenlegi db ről, tök jó lenne. :)
- mi a célja ennek a query - nek, hogy saját magával csinál Descartes szorzatot? Valószínűleg nem kell neked ilyen, de egy jól megfogalmazott cél sokat segítene.
Bocsi. csak most tudtam
Az sql kérés nested tree leírásából vettem ki, a részfa lekérdezésének az sql parancsa. Mivel ezeket most tanulom, még nem igazán tudom értelmezni a teljes SELECT utasítást, pontosabban a WHERE ... BETWEEN ... AND ... részét, illetve miért kell két különböző néven meghívni ugyanazon táblát. Ezért is akadtam el ezen a részen.
Dumpot próbáltam készíteni, de valamiért a phppgadmin 0 bytos sql file-t ad vissza, de majd elküldöm az adatbázis designer által generált utasításokat, csak az másik gépen van.
Amin most dolgozok konkrétan, egy szabadság kérő rendszer. Szabadságok kérése, azok két szintű elfogadása, egyszer a szakmai vezetők által, és véglegesen az intézmény vezető által, illetve kimutatások készítése a kivett szabadságokról.
Ahogy a jogosultságoknak ki kell néznie:
- Honlap tulajdonos: teljes jogkör
- Admin: felhasználókat adhat hozzá tesztelheti a rendszert, más felhasználói névre válthat, és így annak nevében szabadság kérelmet, és törlést kezdeményezhet. Mindenkinek az adatait láthatja, módosíthatja
- Intézmény vezető: az összes kérelmet látja, és véglegesítheti, kimutatásokat készíthet, szabadságot kérhet, mindenki adatait láthatja, nem módosíthat, csak a saját személyes adatait
- Könyvelés: szabadságot kérhet, mindenki adatait láthatja, és teljeskörűen módosíthatja
- Szakmai vezető: a saját munkacsoportján belüli kérelmeket látja, azokat engedélyezheti, a saját dolgozóiról kimutatást készíthet, szabadságot kérhet, a dolgozói adatait láthatja, személyes adatait módosíthatja
- Beosztott: szabadságot kérhet, a saját adatait láthatja, saját személyes adatait módosíthatja. Lehet többféle beosztás, de csak a nevük más, jogosultság ugyanaz)
Szakmai vezetők alá tartozó dolgozók felosztása:
- Központ
---Egy város
- Házisegítség nyújtás
---Több város
---vannak szakmai vezetők, akik alá 1-1 város tartozik, de van akihez több is
- Hajléktalan szálló
--- egy város jelenleg
- Idősek nappali klubbja
---Több város
---vannak szakmai vezetők, akik alá 1-1 város tartozik, de van akihez több is
A városoknál lehet átfedés is, hogy pl egy városon belül több munkaterület van.
Van több is, de valójában egy sémára megy már az egész. Ami még megoldott kell hogy legyen, hogy van olyan szakmai vezető, aki alá több munkaterület is tartozik, illetve, ha valaki szabadságra megy, akkor a helyettesítés. Ez akár az intézményvezetőre is, aki pl most intézményvezető, de egyben a hajléktalanok szakmai vezetője is átmenetileg.
Illetve olyanra akarom, hogy hordozható legyen, pontosabban ne erre legyen konkrétan írva, hanem akár más jogosultsági rendszer is felépíthető legyen, ha lehetséges (pl ahol csak simán van pár jogosultsági szint, mint mondjuk egy egyszerűbb webáruháznál)
Csináltam már egy ilyen rendszert nemrég nekik, de ott teljesen alapszintű a jogosultságok kezelése, és pont ezért átláthatatlan, és bonyolult módosítani, és most szeretném ezt egy átláthatóbb, kezelhetőbb felületre lecserélni. Csak ugy most jött ki, hogy eddig csak az általános adatbázis kezelést ismertem, táblakapcsolatok nélkül, így ezeket mind most ezzel tanulom, az oop-vel együtt. :)
Remélem sikerült érthetően megfogalmaznom. :)
És ezúton is kívánok Neked nagyon boldog karácsonyt! És köszönöm, segítségedet. :)
Semmi gond :)
Nem jó cikkből,
Nem biztos, hogy neked kell. Ezért is kérdeztem, hogy mi a cél. Mindig az legyen az első: meghatározni a jól behatárolt objektív célt. Simán lehet, hogy neked elég ez is:
Specifikációt olvasva egyelőre félre is teheted a nested setet, mert nem kell a megvalósításhoz.
Javaslat1: írj egy listát, kizárólag a jogosultságokról! Ne legyen benne, hogy ki kapja, csak azt sorold fel, hogy az alkalmazásban mit lehet jogosultsághoz kötötten megtenni! Lentről felfelé haladva, pl:
- regisztrálni,
- szabadságot kérni;
- szabit elfogadni 1 szinten,
stb.
Ilyet sose írj le magadnak specifikáció gyanánt, hogy "teljes jogkör", "teljeskörűen módosíthatja", ennél sokkal pontosabban be kell határolni.
Ha a "Honlap tulajdonos" nem te vagy, akkor ezt nem javaslom, inkább legyen erre egy "webfejlesztő" role. Én szoktam olyat meglépni, hogy ez a role id bent van egy eldugott configban is, és az a fv, amivel lekérdezem, hogy adott usernek van-e adott jogosultsága, az minden role esetében true-t ad vissza, ha van a fejlesztői... :)
De nagyon fontos, hogy az egyes funkciók legyenek külön-külön ojghoz kötve, nem pedig az emberek / csoportok. Ez szerintem félre ment, amint nincs kész az első lista jól, addig ne menj tovább.
Javaslat2:
Ne lődd tökön magad olyan funkcióval, hogy
Borzasztóan össze fogod keverni magad, ha vmit logolni fogsz, nem fogod tudni, mikor mi kell legyen sessionben, stb stb.
Emellett tudtommal törvény is tiltja az olyan megoldást, hogy a Gipsz Jakab csak úgy Teszt Elek nevében bármit tegyen az ő tudta és beleegyezése nélkül.
A "Szakmai vezetők alá tartozó dolgozók felosztása" részt pedig veheted teljesen külön, ez egy következő lépés lesz, ez nem jogosultsági kérdés.
Főleg akkor nem, ha
Tehát legyen meg az első lista, az alapján lehet fejleszteni, aztán az legyen egy másik issou, hogy intézmény is van, meg a Hirtelenemelkedő dűlőn intézményvezető Marika néni ne tudja a pesti Józsika szabadságát is jóvá hagyni.
Így szemre akiket adminnak, intézmény vezetőnek, stb hívtál, azok lesznek a csoportok. Az csak az első lista után, meg fogod látni, mennyi mindent kihagytál. :) (Én ezt olvasva azt mondanám, hogy szabadság kérést is adnék a vezetőknek is, ne kelljen emiatt dolgozói csoportba is tenni pl.)
Egy fontos részlet még:
Ennek nem sok értelme van. Megint nem jogosultsági kérdés, hanem cég struktúra(?). Egyelőre nem fontos, de elképzelhető, hogy lesz "Pesti-beosztott" és "Pécsi-beosztott" csoport is, nem jogosultság.
Arra figyelj, hogy ne vegyél fel két Id-val gyakorlatilag azonos értéket ("csak a név a más"), akkor az egy másik elem, nem az, amire gondoltál.
Most olvasom, és értelmezem
húha
Ezen kívül jó lenne tesztadatokkal együtt (amivel te is "játszol"), de ez a rész akkor részemről inkább skip, nincs annyi időm.
Szerk.: Sok helyen van generált key, helyette elképzelhető, hogy jobb egy autoincrement saját Id. Nagyon lassítja az INSERT / UPDATE - et, és ok, hogy a tábla így kisebb, de az index meg sokkal nagyobb.
Végül is akkor most előlről
Akkor a lényeg: határozzam meg a jogköröket részletesen, egy teljesen sima lista, a szervezeti struktúrához viszont már a fa struktúra kell.
A jogosultságokat ilyen formában szedtem össze:
- regisztráció
- tagok alapadatainak módosítása
- tagok kiegészítő adatainak módosítása (pl ezesetben az éves szabadság meghatározása)
- tag inaktívvá tétele
- tag végleges törlése
- a tag munkavégzésének adatainak módosítása (hely, munkacsoport, munkakör)
- szabadság kérése
- szabadság engedélyezése 1. szinten
- szabadság engedélyezése 2. szinten
- kimutatások készítése
- egyéni jogkörök módosítása
- csoport jogkörök módosítása
- új munkavégzés hely hozzáadása
- új munkahely hozzáadása
- új munkakör hozzáadása
- új csoport létrehozása
- csoport módosítása
jó lista! :)
Ez a három biztosan elegendő, hogy egy role legyen:
- csoport jogkörök módosítása
- új csoport létrehozása
- csoport módosítása
Ezek szintén, sanszos, hogy előbbivel azonos role. Ha nem muszáj, ne legyen túl sok role, de ne is vonj össze olyat, ami nem tutibiztos, hogy lehet egy. Tapasztalat, hogy nagyjából egy tartalomtípus egy role. Aki hozzá nyúlhat, az általában mindent meg is tehet vele, max a törlés a kivétel.
- új munkavégzés hely hozzáadása
- új munkahely hozzáadása
- új munkakör hozzáadása
Kimaradt:
- Szabadság letiltás és végleges törlés (tévedésből írta be, stb), de lehet, hogy ez egy role: "saját szabadság létrehozás, szerkesztés, törlés", illetve adminnak hasonló, csak nem sajátra.
- Role létrehozás - update - delete.
- Group delete.
- User -> Group és vissza.
Ez mit jelent?
- regisztráció
Szerintem bárki regisztrálhat (saját magát), legfeljebb legyen elfogadáshoz kötött az aktiválás.
Másvalakit regelni nem igazán tanácsos, ha pl nem használ számítógépet, akkor email fiókja sincs, mindenképp a Marika néni fog a "helyébe lépni".
Viszont az már Role, hogy "ő egy regisztrált User", és ezt célszerű is kicsit külön kezelni (mondjuk Id = 2), hogy Group - al ne lehessen kapni / elveszíteni, ez mindenkinek van, aki nincs letiltva / törölve.
Apropó, User törlése. Id - k miatt nem (sem) célszerű fizikálisan törölni a rekordot, de minden egyes adatát anonymizálni vagy törölni kell, és nem visszafordíthatóvá kell tenni a folyamatot.
Ha van Group, akkor egyéni Role nincs ("egyéni jogkörök módosítása"). Nem fogod tudni lekezelni, amikor változik valami Group-on keresztül (kivéve egy-két nagyon spéci eset).
Ezen kívül ne szögezzük le előre, hogy
Értem én, hogy tetszik a nested set (nekem is :) ), de ha nem feltétlenül kell, akkor minek? * (l. lentebb)
Amúgyis: Role után Group jön, milyen felhasználói csoportokra lesz szükség? Ez megint nem egyenlő a beosztással, vagy a munkavégzés helyével.
Ha valami Role még hiányzik, akkor az esélyes, hogy kiderül, amint életszerű Group-okat akarsz felírni.
Tehát gondold át a Role listát, hiányokat pótold, ha van ami összevonható, azt vondd össze, és jöhet a Group terv.
DB:
- Nem láttam UserData táblát, pedig valahova a "kiegészítő adatok" is kerülnek. Azt gondold ki, hogy lesz-e olyan adatod, amiből 1 Usernek több is lehet. Más a szerkezet, mintha 1-1 a kapcsolat.
- Teli van ALTER-el, elég csúnya dump.. (Tudom (ill. gondolom), nem kézzel írtad.)
- Usernek szerintem minimum LastName és FirstName, de részemről még UserName is "jár".
* Fenti rész legyen előbb rendben, db-terv is legyen hozzá teljes, utána lehet szervezeti struktúra - terv. Ez jól különüljön el fentiektől, mert sanszosan csak ennek a cégnek készül így, más nem fogja tudni használni.
Felülről ("Hely", ami inkább "Munkahely") lefelé haladva, minden egyes "szinten" az a fő kérdés:
"neki milye van, milyen adatokra van szükség, hogy teljesen fedje, amit kell?"
pl Munkahely:
- Id,
- Név,
- Cím,
- Blabla,
- Osztályok ...
Hoppá, többes szám van, ez különálló egység lesz!
Kérdés: nem kell semmi más már Munkahelynek?
Akkor tervezek Osztály-t, ha Munkahely szerintem kész.
Osztály:
- Id,
- MunkahelyId,
- Név,
- Góré (Id),
- GóréHelyettes (Id),
- Blablabla,
- Dolgozók ...
Hoppá, többes szám ...
Nem biztos, ez a legjobb megközelítés, de én nagyjából így szoktam. A céget viszont te ismered.
Szerintem ennyi az egész, nem kell ehhez nested set, annyi, hogy a User-nek lesz egy OsztályId tulajdonsága is. A egy Marika néni képes több osztályon dolgozni, akkor több OsztályId-t kell megvalósítani: lehet pl külön tábla és LEFT JOIN.
Tervezési fázisban célszerű ugyanazt a dolgot mindig ugyanúgy hívni, pl: jogkör = Role. kisebb a félreértés esélye.
Kicsit átvariáltam a
Hozzáadtam egy város táblát is, amit a posta adatbázisa alapján töltöttem fel város nevekkel. Ahhoz kapcsolva lehet majd kiolvastatni a város neveket a varos_id alapján.
Amit még változtattam, hogy beraktam egy segéd táblát a user, és az osztályok közé, mint a roloknál.
Most így néz ki a tábla terv: database_design
Itt vannak a role-ok is: roles
Továbbá csináltam egy sql dumpot is, most mysql-re. Igazából a postgresql-t csak ki akartam próbálni, mert hallottam róla, hogy állítólag gyorsabb, stabilabb mint a mysql. :) Amúgy jól érezted, a másik dumpot is programmal csinálta. A MicroOLAP Database Designer for PostgreSQL-elel. A mostanit kicsit átbabráltam, hogy ne legyen annyi ALTER. Bár ezt phpmyadminnal csináltam, az is tud rendesen szemetelni. :)
Hogy kéne külön kezelni? Mert minden role kapcsolódik egy grouphoz. Legalább is eddig.
dump rossz
Ha már csinálsz egy dump-ot, célszerű azt kipróbálni publikálás előtt.
Mire való ez az új "logos" prefix? Célszerű lenne a nevek terén következetesnek maradni, így már kicsit nehéz követni. uc_wc_id egészen fantasztikus azonosító így első ránézésre... :)
Javaslat:
- Csak angol neveket használj (esetleg csak magyart), ne keverd
- Legyen CamelCase, és nem kell _ sem
- Ne legyen rövidítés oszlopnévben
- Felesleges oszlopnévben a tábla prefix, bonyolult Query-knél ha túl hosszú a táblanév, lehet használni alias-t.
Megint bele lett keverve a Munkahely / Osztály / Stb, pedig még nem látszik, hogy jogosultságok rendben lennének.
UsersRoles tábla nincs. Ezek szerint legalább minden login-nál legalább 4 táblát akarsz join-olni, plusz még amikor jogosultságot kell ellenőrizni. Ahelyett, hogy össz. hármat. Biztos, hogy jó lesz ez így?
Azt látom, hogy eléggé ide-oda kapkodsz, nyilván azért, mert szeretnél már kilóméterekkel előrrébb járni, de ez így nem fog menni, mert csak egyre nagyobb a káosz.
Amíg az alap felhasználókezelés nem működik teljesen jól (mondom működik, nem csak papíron van!), addig nem kellene semmi mással foglalkozni. Ugye ezt már jeleztem, és így segíteni se igen tudok mit, mert csak a kapkodás látszik.
Role-okat is megint kicsit összekeverted. Így, hogy képen van, nem tudok belőle másolni. De.
- Ha az egyszerű dolgozó csak bizonyos státuszig és csak a saját tartalmát (szabi) tudja módosítani, akkor az mindenképpen másfajta szerkesztési Role, mint aki bárkiét bármikor. Ezt kapásból célszerű 2 Role-nak felvenni.
Már amennyiben ez valóban szükséges. (Nem biztos!)
Spéci Role-ok:
1: Fejlesztő - csak az kaphatja, aki valóban az, el nem lehet venni.
2: Regisztrált user - automatikusan megkapja minden érvényes regisztrált user, nem lehet megkapni Group-al és el sem lehet veszíteni. (Mondjuk a letiltott / törölt felhasználó bukja el).
Group alapján csak olyan Role-ok kaphatók / veszíthetők el, amelyek Id > 2. Ennyi.
Namost, kicsit elkalandozva a szabadságokhoz:
HA a szabis rendszerben bármelyik user biztosan dolgozó is, aki szabit vehet ki, AKKOR az alapszintű szabi - szolgáltatásokhoz semmilyen további Role-ra nincs szükség, csak az eggyel fentebbi szinten lévő műveletekhez.
Lássunk egy valóban jó és átgondolt db-t kizárólag a felhasználó- és jogosultság kezelésre, ha az rendben van, akkor talán le is lehetne fejleszteni hozzá az alkalmazást is, és csak ezután variáljunk a szabikkal, helyekkel, stb.
Megj., hogy a címekkel is lesz bajod rendesen, ha az első körben nem fontos, akkor hagyd ki egyelőre.
Igazad van... vissza az alapokhoz
Egy szabadság kérés lépései így néznek ki:
1. A felhasználó bejelentkezik
2. Megkéri a szabadságát (pl. 2017.01.10-től, 2017.01.11-ig, 2 napot)
4. A középvezető engedélyezi a szabadság kérelmet
5. A felsővezető engedélyezi, véglegesíti a szabadság kérelmet (függetlenül a középvezetőtöl - ez kérés, hogy így legyen)
Kivételek:
Ha a felhasználó elírt valamit, és még nincs engedélyezve a szabadság, akkor azt még módosíthatja, vagy törölheti is.
Ha már engedélyezve van már 1 szinten, akkor a kérelem módosítását, vagy törlését kérheti.
Szükség van továbbá szabadságos kimutatások készítésére, ami szintén role-hoz köthető, mert nem mindenki készíthet.
A szabadság törlésére azért van szükség, mert volt már rá példa, hogy valaki megkérte, majd a szabadság előtti napokban visszavonta, még sem akart szabadságra menni, vagy módosul a kérelem, mert mondjuk 2 nappal el akarja csúsztatni a már megkért szabadságot. Viszont a főnök meg mindenről tudni akar még akkor is, ha őt nem is érinti az adott dolgozó (pl. nem a központban dolgozik, így közvetlenül nincs vele kapcsolatban).
A roleok:
- Fejlesztő
minden role-hoz köthető esemény automatikus true értéket kap
- Regisztrált felhasználó
ezzel a role-al módosíthatja a saját adatait
- Szabadság kérés/módosítás/törlés
megkérheti a saját szabadságát, módosíthatja, törölheti.
Az utóbbi két cselekményt befolyásolja, hogy engedélyezve van-e már vagy még nincs (ezt a részt maga a program kezeli majd)
- Felhasználók adatainak módosítása
más felhasználók adatainak módosítása
- Felhasználó inaktívvá tétele
a felhasználó zárolása, hozzáférés megszűntetése (pl megszűnik a szerződés)
- Felhasználó munkaadatainak módosítása
a munkavégzés helyének, jellegének, munkakörének módosítása
- Kimutatások készítése
kivett szabadságok összesítése, nyomtatása
- Munkavégzés helye/munkahely/munkakör módosítás
- Munkavégzés helye/munkahely/munkakör felvétel, törlés
- Csoport létrehozása/módosítása/törlése, beleértve a GroupRole-okat is
- Szabadság engedélyezése/megtagadása 1 szinten
- Szabadság engedélyezése/megtagadása 2 szinten
- Engedélyezett szabadság módosítsa/törlése
már engedélyezett szabadságok módosítása/törlése
sql táblák (most inkább kétszer is átnéztem/kipróbáltam, nem értem hogy lehetett az elsőben a hiba, mert a lefuttatás után másoltam be, de az tény, hogy hibásan lett bevíve)
Remélem holnap :)
Ami helyből látszik:
- mobilon ez a szál mélység már nem olvasható (ez WL hiba)
- nem válaszoltad meg a szerintem legfontosabb kérdést: minden egyes user kérhet szabadság? Mert szerintem igen, és akkor megint van itt felesleges Role.
De összességében már sokkal inkább kerek, ez már emészthető egység. :)
Új szálon
- Nincs character set és collation megadva, mindenképp pótolni kell.
Users- email oszlop is legyen nagybetűs: Email
- FirstName - LastName jellemzően ugyanolyan hosszú, szerintem 128
- varchar - hosszokat érdemes 2 hatványaira beállítani: 50 -> 64, stb
- Indexek legalább név, email legyen felindexelve, biztosan keresel majd rá, de Password mindenképp
- Created: tmiestamp jobb erre a célra, én tennék Updated-et is, ez akár lehet ON UPDATE CURRENT TIMSTAMP is
- Lehet, hogy kéne egy pl Hash oszlop is, amikor bármilyen aktiváló / elfelejtett jelszó linket kiküldesz, azt is teszed vhova
- Status: honnan tudod majd, hogy valaki érvényes user, le van tiltva, törölt, egyéb?
- Lehet, hogy pár személyes adattal még bővíteném (teló, stb), amit legfeljebb nem használunk fel.
Roles- varchar - hossz ugyanúgy
- Name inkább Title nekem, Note pláne Description
- Note text... Egyetlen jogosultság leírása 64k?? Szerintem max varchar(512)
- Title (Name) lehetne
UNIQUE KEYGroups- L. Roles
Kapcsoló táblák / egyéb:
-
ON DELETE NO ACTION ON UPDATE NO ACTION: gyönyörűen lehet inkonzisztens káoszt csinálni így egy kezdetben jó db-ből. Ha mindkettőRESTRICT, akkor hibát fog dobni, ha olyan elemet (pl Roles) akarsz törölni, amire van hivatkozás, és sikertelen a törlés. HaCASCADE, akkor törli a hivatkozást is (vagy update), ami itt nem biztos, hogy hasznos lenne.Folyamat 4-5 pontja (engedélyek) ha jól értem, akkor csak az kell, hogy mindkét engedély meg legyen, mindegy a sorrend.
És ha egy engedély is rajta van, már csak góré tudja módosítani.
Ha 2 van, érvényes.
Majd oda is kell még egy flag vagy státusz, hogy "otthon is maradt a csávó" (=lezárás szerű valami), akkor mehet statisztikákba, innentől már senki nem tudja babrálni.
SZERK.:
- Role-t lehet, hogy csak fejlesztő tudjon felvenni, általában Admin csak Group és GroupRole szinten garázdálkodjon. Mindenképp legyen külön Role a kettő. Amire program dependel, azt ne lehessen kitörölni.
- Roles szövegek lehetnének nyelvi kulcsok is.. :)
Módosítások
Amik módosításra kerültek:
Users tábla:
Az Indexeket hoztam létre, a FirstName, LastName, LoginName, Password-ra. Ezek alapján kell majd keresni a leggyakrabban. Felvettem még egy Phone oszlopot, illetve egy Statust bool értékkel. A későbbiekben akarok még címet, de ezzel most nem foglalkoztam. Bár arra már régebben találtam lehetséges megoldást, hogy mi van olyan esetben, ha a város nem létezik, egy javascript formájában.
Groups tábla:
Ezt nem igazán értettem, hogy mi a L. Role...
Kapcsoló táblák:
Beállítottam őket RESTRIC-re. Gondolkoztam, hogy a DELETE-re CASCADE-de nem voltam benne biztos... Viszont ezen a téren még semmi tapasztalatom nincs... Mert paraszti logikával nézve, ha pl törlök egy Role-t akkor lehet, hogy jó lenne ha a hozzá kapcsolt GroupRole-t is törölné... Nah de még ezzel kísérletezek. :)
Újragondoltam a Role-okat is, mert felvetődött némi módosítás, azok alapján amit írtál...
Átvaritáltam a sorrendeket figyelembe véve, hogy melyek tartozhatnak egy Role csoportba (ez nem egyezik meg a későbbi csoport role-okkal)
1. Fejlesztő
2. Regisztrált felhasználó
3. Munkavégzés helye/munkahely/munkakör módosítás
4. Munkavégzés helye/munkahely/munkakör felvétel, törlés
5. Felhasználók adatainak módosítása
6. Felhasználó inaktívvá tétele
7. Felhasználó munkaadatainak módosítása
8. Csoport létrehozása/módosítása/törlése
9. Group Role hozzáadás/törlés
10. Role felvétele/módosítása
11. Kimutatások készítése
12. Szabadság engedélyezése/megtagadása 1 szinten
13. 1 szinten engedélyezett szabadság módosítása/törlése
14. Szabadság engedélyezése/megtagadása 2 szinten
15. 2 szinten engedélyezett szabadság törlése
Gondolkoztam azon is, hogy csoportokra hogy lehet leosztani. Eddig erre jutottam:
Admin: 3-9, 11
Csoport1: 3-7, 11
Csoport2: 11, 12, 13
Csoport3: 11, 14, 15
A szabadság kérés engedélyezési menetét nem fejtettem ki rendesen:
Megkéred a szabadságot. Amíg nem engedélyezik, addig azt módosíthatod törölheted szabadon...
Engedélyezi a középvezető. Ezután csak a kisfőnök módosíthatja, törölheti. A kérelmező csak kérheti a módosítást/törlést. A góré csak azután látja a kérelmet, ha a kisfőnök jóváhagyta, vagy elutasította. Ezután lesz rá jogosultsága, hogy azt engedélyezze, módosítsa, vagy törölje. Bár a módosítást lehet nem kéne engedni, mert ugye változik az idő, és arról a kisfőnöknek is illene tudni, és beleegyezni... :) Ezen módosítottam is...
Az új dump:
Alakul
A teljesség igénye nélkül: aktív, letiltott, törölt, aktiválásra váró, email cím csere utáni aktiválás, ...
Egy boolean is egy byte a db-ben, legyen inkább tinyint.
RESTRICT vs CASCADE
Gyakorlatilag pusztán hozzáállás kérdése: lusta programozó vagy, vagy jó?
Ha lusta, akkor CASCADE, majd a db motor takarít helyetted (reméljük). Ha jó fejlesztő vagy, akkor örülsz neki, ha a db is elhasal és ordít, ha elb...ál vmit.
Roles szerintem jó így (majd kiderül, ha nem), csoportokat meg bőven ráérsz majd admin felületen kialakítani.
Dump-ra most nincs időm.
public function authHa ez a fv nem azonosít, akkor rossz a neve.
Ha ez
HaveRoleszeretne lenni, akkor lényegesen egyszerűbben meg lehet oldani. De ne ezzel a query-vel kezdd.$developer = FALSEpláne nem is kell, mert azt a jogot is ugyanez a fv mondja meg, hogy van-e neki.De lehet, hogy egyáltalán nem ezt akartad itt vizsgálni?
Mindenesetre a User Role-jainak a vizsgálatához nem kell UserGroups és GroupRoles tábla.
Ha csak Id alapján elég, nem kell szövegesen, akkor csak a User és a UserRoles táblák LEFT JOIN. Ha szöveges is lehet, akkor még Roles is.
(Lehet eddig nem mondtam, de hasznos lenne Roles.Title unique key!)
(De, mondtam. :) )
Lassan de biztosan :)
Egy boolean is egy byte a db-ben, legyen inkább tinyint.
Igen ez igaz... viszont aztnéztem, hogy alapból a bool-t tinyintnek állítja be, így akkor ez már megoldott. :)
És tényleg... már elkeveredtem a rövidítésekben... :) Elvileg megcsináltam mind, de viszont ezt sikerült kihagyni...
Hááát... valahol a kettő között... :) Viszont szeretem látni, hogy mi történik, mert egyrészt nem okoz galibát amit esetleg csak későn veszek észre, másrészt meg abból lehet tanulni ha visszakiabál. :)
A funkció csak egy kísérlet, gondoltam, hogy lesz benne hiba. :) Egy másik cikkben láttam, mikor kutattam ebben a témakörben, és onnan írtam át. A $developer-nek tényleg az lenne a funkciója, hogy megállapítsa, hogy akinek a jogosultságát vizsgálja, fejlesztő, vagy sem. Ha nem fejlesztő, akkor nézze meg, hogy az adott feladat jogosultságával rendelkezik-e
(De, mondtam. :) )
Igen mondtad, és benne is van a dumpban... Mikor kipróbáltam akkor szépen működött is. :)
A javított dump:
Már csak kötöszködök :)
- Nem UNIQUE KEY a Groups.Title (Role.Title igen, azt benéztem előzőleg)
- User.Phone jobban jársz, ha varchar(legalább 16), mert akkor tudod ország-körzet-szám formában tárolni.
- Hint: ON UPDATE CURRENT_TIMESTAMP - et ha egy mód van rá, ne használd ki, egyik biztos megoldás arra, hogy mindig jó időpontok legyenek mentve, hogy mindig csak a PHP idejét használod, és megadod MySql-nek. Sok esetben másik vason fut, és nem egyformán jár a kettő órája.
- Roles.Description nekem NOT NULL lenne szintén, majd beszúrok üres stringet, ha nem használom (de miért ne használnám?).
- Ha helyes magyar ABC sorrendet szeretnél, akkor
COLLATE=utf8_hungarian_ci- UserGroups index ez jobb, érdemes megtenni UserRoles-on is:
itt egy szög egyszerű query, amivel addott (most épp 3-as) jogosultságot ellenőrzöl:
Persze ha szövegesen is kellhet keresni, akkor bejön mellé még a Roles tábla is és még egy feltétel.
U.`Status` > 0jelenti azt, hogy aktív a User, be tud lépni. PHP-ben gyors escape-elési módja egész számoknak az(int) $Value, ez biztos, hogy egész szám lesz (ha pl string, akár sql injection okán és szám nélkül, akkor 0 lesz).Remélem most jó lesz. :)
Átírtam a táblákat. Annyit módosítottam még, hogy a GroupRoles, UserRoles táblákba is beállítottam a UNIQUE INDEXET, hogy ne lehessen egyazon usernek ugyan azt a jogot többször megadni.
Köszönöm az query-t. :) A UserRoles-t, és a GroupRoles-t külön kell lekérdezni?
Én is
Mint az elején is tárgyaltuk, a UserRoles tábla fő szerepe egyfajta "elő-pufferelés", a célja az, amit fenti query-ben is látsz, hogy két (max 3) tábla 1-n join-jából megkapjuk gyorsan valaki jogosultságát.
A Group és GroupRoles táblák szerepe pedig az admin funkciók segítése, hogy ne csak egyesével tudj egy-egy felhasználónak jogokat adni, hanem egyszerre több felhasználónak egyszerre több jogot.
Majd az egy érdekes feladat lesz, hogy admin Group-ot módosít. :)
Ilyenkor:
- Lekéred az összes GroupRoles-t adott Groupra;
- Lekéred az összes User-t (UserGroups), ezeken egyesével mész végig:
- Lekéred a UserRoles-t rá;
- Összehasonlítod GroupRoles-al;
- Amit kell, kitörölsz, amit kell INSERT (UserRoles-ban)
Persze egy kicsit bonyibb lesz a szitu, mert a User több Group-ba is tartozhat, és a másik Group-ból származó jogait nem kéne elvenni. :)
A megoldás egy generikus UserRoles-update-elő mutatvány (class) lesz, ami adott Usert fullosan beállít Group-ok alapján. Amikor pedig Group módosul, ezt a mutatványt kell futtatni minden tagjára (itt majd lehet, hogy érdemes lesz pár ezerben limitálni, hogy ne módosíts olyan csoportot, amiben pl 10000 User van már).
Jogosultság lekérdezés
Hát itt nem értem a kérdést igazán, de valószínűleg igen.
Azért merült fel bennem ez a kérdés, mert az elején úgy gondolkoztam, hogy vannak a csoportok, és annak vannak jogaik. Így mikor vizsgálni kezdem a user jogosultságát, akkor lekérem, hogy milyen csoportba tartozik, és akkor annak a csoportnak milyen jogai vannak. Ebben az esetben nem kell minden usernek külön-külön beállítani, role-okat. De mivel lehet, hogy valakinek csoportokon felüli jogosultsága van, pl a fejlesztő, akkor azt is figyelembe vegye. Ezért volt az UNION kapcsolás. Bár ott kicsit eltúloztam, hogy más role-okat is keres, hisz ott elég csak azt megnézni, hogy fejlesztő-e, elfelejtettem, hogy nem kéne egyéni jogokat adni a felhasználóknak az átláthatóság miatt. :) Illetve ami még lehetséges megoldás, amit írtál is korábban, hogy configba betenni, hogy ki, vagy kik a fejlesztők.
Nem igazán
Nem kell semmi union, a User minden jogosultsága bent van UserRoles ban. Amikor kérdezzük, nem érdekel, hogy honnan van neki adott Role.
Nem tesszük configba, hogy kik a fejlesztők.
Azt tesszük csak configba / kódba, hogy melyek azok a Role ok, amiket Group alapján sem lehet elvenni senkitől (jelenleg ami Id < 3).
Azért, hogy a Group alapú módosítás ne keverjen be a spéci Role okba. Ezeket ugyanúgy csoporthoz rendelni se lehet (GroupRoles), stb.
Ha egyéni jogokat is adsz, akkor az első Group alapú update felül fogja csapni, ami nem jó.
A fejlesztői jogot egyszerűen, db insert el oda tudod adni vagy elvenni. Te, aki hozzá férsz db hez.
Nem olyan bonyolult ez, csak próbáld meg helyén kezelni. :)
Akkor ha jól értem, a
- beállítom a GroupRoles táblán, hogy milyen role-ok tartoznak az adott grouphoz
- ha egy usert hozzáadok a grouphoz, akkor az adott groupe role-jait bemásolom a UserRoles táblába.
javítás:
Erre elfelejtettem még rákérdezni... mire gondoltál ezzel:
Kicsit több
...
akkor az adott groupe role-jait bemásolom a UserRoles táblába
User update:
- Lekéred UserGroups-ból, hogy melyik csoportok(!)ba tartozik
- JOIN GroupRoles, hogy meg legyen az összes szükséges jog
- A szép megoldás: Összehasonlítás UserRoles-al, és csak azt insert / delete, amit kell (pl. azért, hogy tudd követni mit mikor kapott).
- B lustáknak: kitörlöd összes jogát UserRoles-ból (marad a két spéci!), aztán beszúrod amit join-oltál előbb.
Fontos, hogy amit összeszedsz összes jogot, azt érdemes group by -olni, hogy ne duplikálj rekordot UserRoles-ban.
Pont arra, amit írtam ( :) ): ha többnyelvű a rendszer, akkor ide nem kész szöveget írunk, csak a kulcsot hozzá, hogy megjelenítéskor a kívánt nyelven írjuk ki.
És miért ne lenne többnyelvű? ;)
User módosítás
Az elindító class:
Sajnos nem minden esetben működik...
Szerk:
Nah meg nézem kimaradt a csoport törlés...
Önállóan :)
Egy észrevétel: számomra a DAO (Data Access Object) egyetlen tábla egyetlen rekordját testesíti meg. Több rekordot már DataList reprezentál.
Egy lehetséges megoldásként
Ajjaj, nem jót mondtam
Ha már a kész a megoldás, és minden szempontból jól is műxik, akkor tök jó, ha megosztod.
Annak már jóval kevesebb értelmét látom, hogy ott van 100 - 300 sor, amikre hivatkozik, abból még részletek itt-ott, és pár mondat, aminek a vége az, hogy "még nem mindenütt műxik jól, ezeket javítom". Vagyis: "kár, hogy átnézted, mert más lesz, de még nem mondom meg, hogy mi". Kicsit sarkítottam, bocsi. :)
De. Nagyon fontos, hogy az én véleményem csakis vélemény, nem vagyok se moderátor, se semmi hasonló, szóval azt küldj be továbbra is, amit csak akarsz, ha az nekem sorozatosan nem tetszik, hát akkor nem olvasom. Ha WL-en nem való olyat beküldeni, majd szólnak moderátorok-szerkesztők és / vagy törlik.
Hát nem is lehet akármit :)
Én még törölni sose akartam, ha egy szál nagyon offba ment, akkor jeleztem szerkesztőknek, hogy tőlem törölhető - és eldöntik.
Így van ez, kirakod, mikor még csiszolatlan: örök időkre megmarad az utókornak, hogy bizony kapkodtál! :-D
Commentet szerkeszteni is csak egy ideig és / vagy addig lehet, míg nincs rá válasz. Én ilyenkor is csak hozzáírni szoktam, "Szerk:" kezdettel.
Igazad van! :)
Viszont akkor most itt a már működő adatbázis, illetve azok egyes sql parancsok, amiket használok. Természetesen a User tábla csak alap adatokat használ még, illetve a nyelvi kulcsok még nincsenek megcsinálva.
Az
ON DUPLICATE KEY UPDATE Id = VALUES(`Id`)sor kezeli le, hogy ne kerülhessen dupla bejegyzés a táblába.Szóvak úgy érzem, hogy jöhet a következő fázis, amit az elején belekevertem a jogosultságokba... A cég hierarchia felépítése.