Jogosultság rendszer

A ConyCMS jogosultság kezelő rendszerének az alap működése.

2022.01.10 — Posted by Webb & Flow


Alapelvek

A felhasználóknak alapesetben semmilyen joga nincs egy portálban, akkor sem, ha magát a portált eléri a projekt listában.

A jogokat entitásonként kell beállítani, így teljesen szabadon lehet szabályozni, hogy egy konkrét felhasználó milyen menüpontokat lát.

Az entitásokon belül minden elérhető funkció külön szabályozható, hogy a felhasználó eléri-e, illetve minden adat mezőre külön megadható, hogy a felhasználó szerkesztheti-e, illetve ha nem szerkesztheti, akkor láthatja-e a beállított értéket.

A tartalmak jogosultsági rendszere ugyanezeket az alapelveket követi, de valamivel összetettebb.

Entitás szintű jogok

Minden entitáshoz létezik egy ADMIN jog, ami automatikusan minden egyéb, az adott entitáshoz tartozó jogot megad a felhasználónak.

Entitás elérése

Ahhoz, hogy az adott entitás bármilyen funkcióját elérje a felhasználó, engedélyezni kell a hozzáférést, ezt az ACCESS jog megadásával tehetjük meg.

Entitás listázása más entitás felületeken

Egyes entitások szerkesztése során tudnunk kell listázni más entitásokat akkor is, ha ahhoz az entitáshoz nem akarunk hozzáférést adni a felhasználónak. Ezt a SELECT jog megadásával tehetjük meg. A SELECT jog nem igényel semmilyen más jogot, de a listázáskor kizárólag az aktív bejegyzéseket engedi listázni, és az adatban kizárólag a mindig látható mezők értékeit adja vissza a rendszer.

Ilyen mezők például:

  • azonosító
  • név (ha van ilyen mező)
  • technikai leírás
  • ...

Entitás listázása és megtekintése

Amennyiben az entitást el akarja érni a felhasználó, az ACCESS jog mellett meg kell adni, hogy melyik bejegyzéseket láthatja.

Amennyiben egy bejegyzést láthat a felhasználó az azt jelenti, hogy:

  • látja a lista oldalon
  • meg tudja nyitni a bejegyzés adatlapját
    • ha van szerkesztési joga, akkor itt tudja szerkeszteni is (lásd később)

Ezt három különböző mező együttes értéke alapján dönti el a rendszer:

  • státusz
    • aktív
    • archivált
    • törölt
  • zárolt
    • igen
    • nem
  • látható
    • igen
    • nem

Mind a három mezőhöz tartoznak különböző jogok, amiket meg kell adni, attól függően, hogy mit szeretnénk, hogy láthasson:

  • státusz
    • LIST_IF_ACTIVE
      • láthatja az aktív státuszú bejegyzéseket
    • LIST_IF_ARCHIVED
      • láthatja az archivált bejegyzéseket
    • LIST_IF_TRASHED
      • láthatja a törölt bejegyzéseket
  • zárolt
    • LIST_IF_LOCKED
      • láthatja a zárolt bejegyzéseket
    • LIST_IF_UNLOCKED
      • láthatja a nem zárolt bejegyzéseket
  • látható
    • LIST_IF_VISIBLE
      • láthatja a látható bejegyzéseket
    • LIST_IF_INVISIBLE
      • láthatja a nem látható bejegyzéseket

Amennyiben a felhasználónak megadjuk a következő jogokat:

  • LIST_IF_ACTIVE
  • LIST_IF_UNLOCKED
  • LIST_IF_VISIBLE

akkor láthatja az aktív, nem zárolt, látható bejegyzéseket.

De ha a következő jogokat adjuk meg:

  • LIST_IF_ACTIVE
  • LIST_IF_UNLOCKED
  • LIST_IF_LOCKED
  • LIST_IF_VISIBLE

akkor láthatja az aktív, látható tartalmakat, azaz a zárolt mező értéke részletkérdés, mivel minden állapotát láthatja a felhasználó.

Amennyiben nem adunk a felhasználónak egyéb jogokat, kizárólag a mindig látható mezőket fogja látni.

Minden más mezőre külön meg kell adni, hogy láthatja-e vagy sem.

Vagy be lehet állítani a VIEW_ALLFIELDS jogot, amivel automatikusan minden mezőt lát, vagy mezőnként be kell állítani a jogokat.

Minden entitásnál megadhatók a következő jogok:

  • VIEW_VERSIONMETA
    • láthatja a bejegyzés létrehozási és utolsó szerkesztési idejét, illetve a létrehozó és utoljára szerkesztő felhasználó nevét
  • VIEW_SHORTDESCRIPTION
    • láthatja a bejegyzés rövid, technikai leírását
  • VIEW_TECHCOMMENT
    • láthatja a bejegyzés technikai megjegyzését
  • VIEW_EDITABLE
    • láthatja, hogy mi a bejegyzés szerkeszthetőségi beállítása
  • VIEW_VISIBLE
    • láthatja, hogy mi a bejegyzés láthatósági beállítása
  • VIEW_WEIGHT
    • láthatja a bejegyzés súlyát

Ezek mellett pedig entitásonként az egyedi mezőkre is be lehet állítani a jogokat.

Például VIEW_CODE azoknál az entitásoknál, amiknek van forráskód mezeje.

Entitás létrehozása

Új bejegyzés létrehozásához az ADD jogra van szükség.

A létrehozáskor a kötelező mezőket meg kell adnia a felhasználónak, így ezekre automatikusan kap szerkesztési jogot.

Egyes entitások létrehozásakor egy listából ki kell tudni választani egy másik kapcsolódó entitást, ebben az esetben a kapcsolódó entitásokra SELECT jogot kell kapnia a felhasználónak, különben nem tudja megadni a szükséges adatokat.

Ilyen például a normál tartalom, aminek a létrehozásához tudnia kell listázni a fő és alkategóriákat, valamint a ContentType-okat.

Entitás szerkesztése

Egy bejegyzés akkor szerkeszthető, ha aktív státuszú és nem zárolt, és

  • szerkeszthetőre van állítva, és a felhasználónak van EDIT_IF_EDITABLE joga
  • vagy csak olvashatóra van állítva, de a felhasználónak van EDIT_IF_READONLY joga

Így megoldható, hogy egyes bejegyzéseket ne tudjanak szerkeszteni az alap felhasználók, csak az adminok, akiknek van EDIT_IF_READONLY joga is.

A státusz, illetve a zárolt állapot módosítása külön jog, lásd később.

Attól, hogy egy bejegyzést tud a felhasználó szerkeszteni, alapesetben semmilyen mezőt nem szerkeszthet utólag, ezekhez be kell állítani a mező szintű jogokat. A kötelező mezőket is be kell állítani, és az utólagos szerkesztési jogot nem kapja meg automatikusan azért, mert van ADD joga.

Amennyiben egy mezőre van a felhasználónak EDIT joga, az automatikusan megadja az adott mező VIEW jogát is.

Például ha van EDIT_CODE joga forráskód mezővel rendelkező entitásnál, és a bejegyzés zárolt, azaz épp nem szerkeszthető, akkor is látja a forráskód mezőt, ha nincs külön megadva a VIEW_CODE jog.

Vagy be lehet állítani az EDIT_ALLFIELDS jogot, amivel automatikusan minden mezőt tud szerkeszteni, vagy mezőnként be kell állítani a jogokat.

Minden entitásnál elérhető jogok:

  • EDIT_SHORTDESCRIPTION
    • a technikai leírást szerkesztheti
  • EDIT_TECHCOMMENT
    • a technikai kommentet szerkesztheti
  • EDIT_EDITABLE
    • beállíthatja, hogy az adott bejegyzés szerkeszthető-e
  • EDIT_VISIBLE
    • beállíthatja, hogy az adott bejegyzés látható-e
  • EDIT_WEIGHT
    • beállíthatja az adott bejegyzés súlyát

Ezek mellett pedig entitásonként az egyedi mezőkre is be lehet állítani a jogokat.

Például EDIT_CODE azoknál az entitásoknál, amiknek van forráskód mezeje.

Entitás státusz állítás

Egy adott bejegyzésnek 3 státusza lehet:

  • aktív
  • archivált
  • kukába rakott

A státusz állításra három, egymástól független joga lehet a felhasználónak:

  • ACTIVATE
    • egy archivált rakott bejegyzést tud újra aktiválni, vagy a kukából visszahozni
  • ARCHIVE
    • egy aktív bejegyzést tud archiválni, vagy a kukából visszahozni archivált státusszal
  • TRASH
    • egy aktív vagy archivált bejegyzést tud a kukába rakni

Entitás zárolás és feloldás

Az entitás vagy zárolt, vagy nyitott állapotban lehet. Ezeknek az állítására a felhasználónak két, egymástól független joga lehet:

  • LOCK
    • egy nyitott bejegyzést tud zárolni
  • UNLOCK
    • egy zárol bejegyzést tud kinyitni

Entitás changelog-jainak elérése

Egy adott bejegyzés changelog bejegyzéseit akkor éri el a felhasználó, ha van CHANGELOG_VIEW joga.

Ekkor eléri az összes korábbi változtatást, annyi időre visszamenőleg, amíg a rendszer tárolja, és láthatja, hogy mikor ki és mit változtatott.

Azt, hogy egy mező pontosan milyen értékről mire változott, csak akkor látja, ha az adott mezőre van megtekintési joga.

Entitás milestone létrehozása

Egy adott bejegyzésről akkor tud a felhasználó milestone-t készíteni, ha van MILESTONE_ADD joga.

Ekkor meg tudja adni a milestone opcionális nevét, de külön jog nélkül nem tudja azt megnézni.

Entitás milestone listázás és megtekintés

Egy adott bejegyzés milestone-jait akkor tudja a felhasználó listázni és megnézni, ha van MILESTONE_VIEW joga.

Ekkor látja az összes milestone-t, azt, hogy ki és mikor hozta azt létre, és a bejegyzés a milestone létrehozásának pillanatában lévő állapotát. Az egyes mezőket akkor látja a felhasználó, ha azokra van megtekintési joga.

Entitás milestone szerkesztés és megszüntetés

Egy adott milestone-t akkor tud a felhasználó szerkeszteni, ha van MILESTONE_EDIT joga.

Ekkor át tudja azt nevezni, illetve tudja archiválni vagy kukába rakni.

Entitás visszaállítása egy milestone-ra

Amennyiben a felhasználó meg tudja nézni a milestone-okat, vissza tudja egyre állítani a bejegyzést, amennyiben van RESTORE joga.

Ebben az esetben a bejegyzés teljes állapotát visszaállítja, azaz azokat a mezőket is, amiket nem lát, vagy nem tud szerkeszteni. Mivel egy korlátozott felhasználó nem lát minden mezőt, így nem is tudja ellenőrizni, hogy jó-e minden egy milestone visszaállítás után, így érdemes olyan felhasználóknak RESTORE jogot adni, akik az adott bejegyzés összes mezejét láthatják.

Tartalmak jogosultság rendszere

Az összes tartalom fajta a fent leírt jogosultság rendszer egy kiterjesztett változatát használja.

Tartalom fajták: Tartalom fajták és típusok

A tartalmak esetén mezőnként meg lehet adni a hozzá tartozó Content Type-ban, hogy az adott mező látható, illetve szerkeszthető-e.

Ezután a flehasználó jogai között nem azt adhatjuk meg egy mezőhöz, hogy láthatja, illetve szerkesztheti-e, hanem:

  • láthatja a mezőt, ha az láthatónak van beállítva (VIEW_*_IF_VISIBLE)
  • láthatja a mezőt, ha az rejtettnek van beállítva (VIEW_*_IF_INVISIBLE)
  • szerkesztheti a mezőt, ha az szerkeszthetőnek van beállítva (EDIT_*_IF_EDITABLE)
  • szerkesztheti a mezőt, ha az csak olvashatónak van beállítva (EDIT_*_IF_READONLY)

Ezzel sokkal pontosabban lehet beállítani, hogy egy adott felhasználó egy adott típusú tartalomnál melyik mezőket láthatja, illetve szerkesztheti.

A következő mezőkre nem lehet beállítani, hogy látható, illetve szerkeszthető-e, így ezekre a többi entitásnál leírt jogosultság vonatkozik (azaz csak azt lehet megadni, hogy láthatja-e, illetve szerkesztheti-e):

  • Technical (short) description
  • Technical comment
  • Weight
  • Visibility (látható-e maga a bejegyzés)
  • Editable (szerkeszthető-e maga a bejegyzés)

Vannak mezők, amik minden esetben láthatók, illetve minden esetben szerkeszthetők, ezekre nem kell megadni külön jogot.

Az ExternalData esetén nem lehet mezőnként adni jogokat, hanem ez egész External Data mezőre lehet a fenti négy jogot beállítani, és a Content Type-ban External Data mezőnként lehet beállítani, hogy az adott mező látható, illetve szerkeszthető-e.

A tartalmaknál egy külön jogosultság a publikálás, melyet a következő jogokkal lehet szabályozni:

  • EDIT_STATE_IF_EDITABLE
    • szerkesztheti az állapotot, ha az szerkeszthetőnek van beállítva
  • EDIT_STATE_IF_READONLY
    • szerkesztheti az állapotot, ha az csak olvashatónak van beállítva
  • SET_STATE_PUBLICABLE
    • beállíthatja az állapotot publikálhatóra
  • SET_STATE_LISTABLE
    • beállíthatja az állapotot listázhatóra

Amennyiben egy felhasználónak nincs valamilyen SETSTATE joga, de szerkesztheti a state mezőt, akkor a következő állapotok között választhat:

  • Under construction
  • Waiting for acknowledgement

Ebben az esetben ha a felhasználó egy már publikált tartalmat szerkeszt, akkor az a tartalom automatikusan visszaáll Under construction állapotra, hogy ne tudjon már éles oldalon jóváhagyás nélkül módosítást csinálni.

Felhasználói csoportok

Azért, hogy ne kelljen minden felhasználónak külön-külön minden szükséges jogot beállítani, létre lehet hozni felhasználói csoportokat, és ezeknek a csoportoknak beállítani az egyes jogokat. Ezután a felhasználóknál már csak meg kell adni, hogy melyik csoportok jogosultságait örököljék meg.

A csoportoktól örökölt jogok mellett ugyanúgy be lehet állítani egyedi jogokat a felhasználónak.

Előfordulhat, hogy egy felhasználó egy csoport miatt megkap egy olyan jogot, amire nincs szüksége, ebben az esetben meg lehet adni az adott felhasználónál, hogy azt a konkrét jogot ne kapja meg annak ellenére sem, hogy egy vagy több csoport miatt megkapta volna.

Portál tulajdonos

A portál tulajdonos egy kiemelt felhasználó, akinek admin jogosultsága van az egész portálhoz. Ezt a felhasználót tényleges munkára nem szabad használni, csak arra, hogy a többi felhasználót meghívja, és minimum egynek adjon a felhasználó kezeléshez szükséges jogokat, hogy onnantól az a felhasználó tudja a többiek jogait beállítani.