Uživatelské role a oprávnění v Drupalu: Jak univerzity řídí, kdo může co upravovat

Univerzitní webová platforma může mít až několik set editorů: fakultní administrátory, sekretářky kateder, pracovníky komunikace, knihovníky a studentské výpomocníky. Drupal seskupuje to, co může každý z nich dělat, do rolí a uděluje oprávnění těmto rolím, nikoli jednotlivcům. V tomto článku popisujeme strukturu rolí, která odpovídá organizaci kampusu, jak dát každé katedře redakční kontrolu nad vlastními stránkami, která oprávnění udělují mnohem víc, než jejich názvy naznačují, a jak odebrat přístup, když lidé odejdou.

Většina návodů na toto téma dostatečně vysvětlí mechaniku a poté skončí u obecného příkladu. To ponechává bez odpovědi tu těžší otázku: jak převést organizaci s fakultami, katedrami, výzkumnými centry a proměnlivým studentským personálem do schématu oprávnění, které malý centrální tým skutečně dokáže spravovat? Níže si tento převod projdeme krok za krokem a pojmenujeme klíčová oprávnění a contributed moduly, které jsou v jednotlivých krocích zapojeny.

Jak fungují role a oprávnění v Drupalu

Každá akce na webu postaveném na Drupalu se řídí oprávněním. Každé oprávnění pokrývá jednu akci nebo malou skupinu akcí a oprávnění definují moduly, které tyto akce poskytují. Místo udělování oprávnění jednotlivým účtům je Drupal seskupuje do rolí a uděluje roli.

Tento rozdíl má na univerzitní úrovni zásadní význam. Když sekretářka katedry odejde, odeberete jednu roli z jednoho účtu, místo abyste procházeli seznam jednotlivých oprávnění. Když komunikační oddělení rozhodne, že editoři už nesmí mazat stránky, změníte jednu roli a rozhodnutí se uplatní na všechny, kdo ji mají.

Tři role, se kterými začíná každý web

Nový web na Drupalu má roli anonymního uživatele pro návštěvníky, kteří nejsou přihlášeni, a roli přihlášeného uživatele, kterou automaticky získá každý přihlášený účet. V závislosti na instalačním profilu může existovat i role administrátora, které jsou přiděleny všechny dostupné oprávnění na webu.

Z toho plynou dva zvyky. Oprávnění udělená roli přihlášeného uživatele se vztahují na každý účet, který kdy vytvoříte, takže tato role by měla na platformě se stovkami editorů zůstat téměř prázdná. A s rolí administrátora by se mělo zacházet jako s malou, jmenovitě vedenou skupinou, nikoli jako s pohodlným řešením pro kohokoli, kdo potřebuje něco rychle vyřídit.

Účet uživatele 1 a proč by v něm nikdo neměl pracovat

První účet vytvořený při instalaci má interní ID 1 a liší se od všech ostatních účtů. Bez ohledu na to, jaké role má nebo nemá, uživatel 1 může na webu provést jakoukoli akci: prohlížet a upravovat veškerý obsah, upravovat libovolný účet, měnit konfiguraci, instalovat a odinstalovávat moduly a spouštět aktualizační skript. Samotná dokumentace Drupalu jej přirovnává k root účtu na linuxovém serveru. Navíc jej nelze smazat přes administrační rozhraní.

Dokumentace Drupalu uvádí čtyři důvody, proč vytvářet samostatné administrátorské účty místo sdílení tohoto jednoho, a každý z nich má na univerzitě větší váhu než na malém webu.

• Akce na webu se zaznamenávají do logu. Pokud si celý webový tým sdílí jeden účet, log vám neřekne, kdo změnil domovskou stránku.
• Roli administrátora lze nastavit bezpečněji než účet uživatele 1, takže omylem kliknutí nemůže odinstalovat modul.
• Odpovědnosti lidí se mění. Role lze u běžného účtu přidávat a odebírat; sdílené přihlašovací údaje nelze odebrat jen jedné osobě.
• Autorství obsahu se zaznamenává a často zobrazuje. Sdílené účty znemožňují zjistit, kdo danou stránku napsal.

Praktické pravidlo zní: uchovávejte přihlašovací údaje k uživateli 1 v trezoru hesel instituce, používejte je pouze pro obnovu a údržbu platformy a každému administrátorovi dejte jmenovitý účet s rolí administrátora.

Role se sčítají, nikdy neodečítají

Uživatel může mít současně několik rolí a oprávnění z těchto rolí se sčítají. Jádro Drupalu neobsahuje žádný mechanismus, kterým by jedna role mohla odebrat oprávnění udělené jinou rolí.

Tohle týmy pravidelně zaskočí. Web má roli editora, který může mazat obsah, a někdo rozhodne, že noví zaměstnanci by neměli mazat vůbec nic, tak vytvoří omezenou roli editora a přiřadí ji vedle té stávající. Daná osoba teď drží obě role a oprávnění mazat stále existuje. Jediný způsob, jak oprávnění odepřít, je vytvořit roli, která je nikdy neměla. Když schéma začne vyžadovat „odečítací“ logiku, je to signál, že je třeba role přepracovat, ne přidávat další.

Model rolí, který odpovídá skutečnému fungování univerzity

Struktury rolí na kampusech obvykle selhávají jedním ze dvou způsobů. Buď existují čtyři role a každá fakulta si stěžuje, že nemůže vykonávat vlastní práci, nebo existuje šedesát rolí vytvořených postupně podle jednotlivých požadavků a nikdo si nepamatuje, co polovina z nich vlastně uděluje.

Struktura, která obstojí v čase, obvykle odděluje dvě otázky, které se snadno zamění. Jaký druh práce daná osoba dělá a ve které části webu ji vykonává? Role Drupalu dobře odpovídají na první otázku a špatně na druhou, proto níže následuje část věnovaná redakčnímu území.

Pokud jde o první otázku, většinu institucí pokryje pět úrovní:

• Administrátor platformy. Jmenovitá skupina dvou až čtyř lidí z centrálního IT oddělení, kteří mají roli administrátora a mají na starosti konfiguraci, moduly a aktualizace.
• Centrální editor. Pracovníci komunikace a marketingu, kteří publikují napříč celým webem, včetně domovské stránky a stránek na úrovni instituce.
• Editor jednotky. Pracovníci fakult a kateder, kteří vytvářejí a publikují obsah ve vlastní oblasti. Jde zdaleka o nejpočetnější skupinu.
• Přispěvatel. Akademici, studentští výpomocníci a příležitostní přispěvatelé, kteří připravují obsah, jenž publikuje někdo jiný.
• Divák. Účty, které existují kvůli přístupu k omezeným stránkám, nikoli kvůli úpravám, například k interním dokumentům s pravidly určeným pouze zaměstnancům.

Před přidáním šesté úrovně stojí za to aplikovat dva testy. Lišila by se nová role od existující o více než dvě oprávnění? A bude ji kdy mít kdokoli jiný než žadatel? Role vytvořená pro jednu osobu je vlastně udělení oprávnění s několika kroky navíc a zůstane existovat i mnoho let poté, co daná osoba odejde.

Dát katedrám vlastní redakční území

Role odpovídají na to, co může daná osoba dělat, ale ne na to, kde to může dělat. Role editora jednotky, která uděluje oprávnění upravovat jakoukoli stránku, umožní katedře biologie upravovat i stránky přijímacího řízení. Řešení tohoto problému vyžaduje druhou vrstvu a Drupal nabízí dva zavedené přístupy.

Přístup založený na sekcích pomocí modulu Workbench Access

Modul Workbench Access vytváří redakční řízení přístupu založené na hierarchii, kterou už máte – typicky taxonomii fakult a kateder nebo struktuře menu webu. Obsah je při vytvoření zařazen do redakční sekce, uživatelé jsou přiřazeni k sekcím podle účtu nebo role a mohou pracovat pouze s obsahem ve svých sekcích nebo sekcích pod nimi. Verze 2.0.5 byla vydána v září 2026 a podporuje Drupal 9, 10 a 11. Podle hlášení jej používá zhruba osm tisíc webů a jeho vývoj sponzorovala společnost Palantir.net s podporou Charles Darwin University.

Dvě omezení uvedená v jeho vlastní dokumentaci stojí za pečlivé přečtení, než na něm začnete stavět. Modul neuděluje redakční práva; pouze omezuje obsah, se kterým může uživatel pracovat, takže samotná oprávnění pro vytváření a úpravy je stále nutné udělovat přes role. A řídí pouze přístup k úpravám, ne to, kdo si může prohlížet publikovaný obsah.

Právě hierarchie je to, díky čemu se tento přístup hodí pro vysoké školství. Pracovník komunikace fakulty přiřazený k sekci fakulty dědí přístup ke každé katedře pod ní, zatímco sekretářka katedry přiřazená k jedné katedře vidí pouze tu. Když vznikne nové výzkumné centrum, přidá se do hierarchie, aniž by bylo třeba vytvářet novou roli.

Kdy se lépe hodí modul Group než sekce

Modul Group volí jiný přístup. Místo zařazování obsahu do hierarchie vytváří kolekce s vlastním členstvím a vlastními rolemi uvnitř. Někdo může být administrátorem jedné skupiny a obyčejným členem jiné a role skupin jsou oddělené od rolí platných pro celý web. Používá jej zhruba osmnáct tisíc webů.

Group se hodí pro případy, kdy je hranicí členství, nikoli organizační pozice: výzkumný projekt s jmenovitě uvedenými spolupracovníky ze tří fakult, konferenční výbor, komunita absolventů se soukromým obsahem. Tam, kde hranice kopíruje organizační strukturu, jsou jednodušší na provoz sekce.

Výběr verze vyžaduje na konci roku 2026 zvýšenou pozornost. Větve 2.x a 3.x podporují Drupal 10 a 11, větev 8.x-1.x dosáhla konce podpory společně s Drupalem 10 v polovině roku 2026 a větev 4.x pro Drupal 11.4 a vyšší je ve fázi alpha. Platforma, která se rozjíždí nyní, by neměla začínat na nejstarší větvi.

Role napříč multisite platformou

Na platformě, kde každá fakulta provozuje vlastní web z jedné společné kódové základny, se role a uživatelé mezi weby standardně nesdílejí. Každý web má vlastní účty a vlastní konfiguraci rolí, což je výhoda pro autonomii, ale zátěž pro konzistenci: vylepšení definice role na jednom webu se nikde jinde neprojeví. Export konfigurace rolí a její nasazení napříč weby udržuje definice identické, i když účty zůstávají oddělené. Širší kompromisy této architektury jsme popsali v článku Správa univerzitních webů pomocí Drupal Multisite.

Je to i bod, ve kterém se stává viditelnou volba mezi multisite a sekcemi. Pokud katedry potřebují samostatné weby, role existují na úrovni jednotlivého webu. Pokud potřebují jen oddělené území v rámci jednoho webu, tuto práci odvedou sekce.

Oprávnění, která tiše udělují úplně všechno

Některá oprávnění vypadají jako úzce zaměřené administrativní usnadnění, ale v praxi jsou rovnocenná předání celého webu. Drupal sám ta nejnebezpečnější označuje: oprávnění může být v definici modulu deklarováno s příznakem omezeného přístupu, díky čemuž stránka s oprávněními vedle něj zobrazí standardní bezpečnostní varování. Jádro to využívá například u oprávnění pro správu textových formátů a filtrů.

Na stránce s několika stovkami zaškrtávacích políček je snadné toto varování přehlédnout, proto si zaslouží, abychom je jmenovitě uvedli.

• Správa oprávnění. Kdokoli s tímto oprávněním může sobě nebo komukoli jinému udělit jakékoli oprávnění na webu, včetně tohoto samotného.
• Správa uživatelů. Umožňuje upravovat libovolný účet. V kombinaci s výše uvedeným oprávněním, nebo na webu, kde lze upravovat administrátorský účet, je to cesta k úplné kontrole.
• Správa textových formátů a filtrů. Řídí, jaký HTML kód je povolen a které role smí který formát používat. Uvolnění formátu je způsob, jak se přes editor dostane do webu injektáž skriptů.
• Obejít kontrolu přístupu k obsahu. Přebije všechna ostatní oprávnění k obsahu, včetně čehokoli, co vynucuje Workbench Access nebo Group.
• Správa konfigurace webu. Zasahuje do nastavení, která ovlivňují celou platformu, ne jen jednu sekci webu.
• Správa modulů. Instalace kódu je nejpřímější cesta ke spuštění libovolného kódu na serveru.

Pravidlo, které z toho plyne, je stručné. Tato oprávnění patří výhradně k roli administrátora platformy a nikam jinam. Když přijde požadavek na některé z nich, užitečnou odpovědí je zeptat se, co daná osoba vlastně potřebuje udělat, protože odpověď je téměř vždy užší oprávnění nebo přiřazení k sekci.

Stojí za to opravit jedno tvrzení, které koluje ve starších textech na toto téma: že contributed moduly jsou ze své podstaty méně bezpečné než jádro. Contributed moduly se stabilními vydáními spadají pod bezpečnostní politiku Drupalu (security advisory policy) a všechny moduly zmíněné v tomto článku toto pokrytí mají. Co se skutečně liší, je stav údržby, který je uveden na stránce každého projektu a který je třeba zkontrolovat.

Nechat katedry, aby si spravovaly vlastní lidi

Při několika stovkách editorů se z každé změny účtu procházející centrálním IT oddělením stává fronta. Katedra v září najme administrátorku a týden čeká na přístup k úpravám. Instinktivní řešení je dát vedoucímu katedry možnost spravovat uživatele, což znamená udělit oprávnění správy uživatelů a správy oprávnění, což zase znamená, že si vedoucí katedry nyní může udělit cokoli.

Právě k tomu slouží modul Role Delegation. Vytváří pro každou roli na webu samostatné oprávnění „přiřadit“, takže administrátor fakulty může dostat schopnost přiřazovat roli přispěvatele a nic víc. V účtových formulářích a hromadných operacích na seznamu uživatelů vidí widget pro přiřazování rolí, aniž by vůbec měl oprávnění správy oprávnění. Podle hlášení jej používá více než padesát tisíc webů a jeho aktuální verze podporuje Drupal 10.3 a 11.

Delegování funguje nejlépe s pravidlem, které role lze delegovat: editor jednotky a přispěvatel ano, centrální editor a administrátor platformy ne. Díky tomu zůstává každodenní zapracovávání nových lidí lokální záležitostí, zatímco role se skutečnou mocí zůstávají u centrálního týmu.

Přiřazování rolí z identitního systému kampusu

Ruční přiřazování se na úrovni kampusu neškáluje a ani nemusí. Když se zaměstnanci přihlašují přes poskytovatele identity instituce, mohou atributy uvolněné při tomto přihlášení přímo řídit přiřazení role, takže se členství v adresářové skupině stane rolí v Drupalu, aniž by se kdokoli dotkl účtu. Stránku ohledně autentizace jsme pokryli v článku Integrace SSO se SAML, Shibboleth, LDAP a CAS; následuje to, co se děje poté, co identita dorazí.

Toto poskytují dvě rodiny modulů. Modul simpleSAMLphp Authentication nabízí okamžité (just-in-time) vytváření účtů a automatické přiřazení rolí z atributů SAML a stále je široce nasazován. Jeho stránka projektu má nyní status „minimálně udržovaný“ a sám jeho správce doporučuje zvážit místo něj modul SAML Authentication, který má mnohem menší řetězec závislostí. Tento druhý modul řeší přiřazování rolí přes svůj submodul user roles a doprovodný modul mapuje atributy SAML na členství ve skupinách Group pro instituce používající skupiny místo sekcí.

Ať už zvolíte jakoukoli cestu, tři návrhová rozhodnutí jsou důležitější než samotný výběr modulu. Rozhodněte, který atribut je autoritativní, obvykle adresářová skupina spíše než pole s pracovní pozicí. Rozhodněte, co se stane při každém přihlášení: zda se role přepočítávají pokaždé, díky čemuž je odebrání automatické, nebo se přiřazují jen jednou při vytvoření účtu, což automatické není. A ponechte malou sadu rolí mimo automatizované mapování, protože role administrátora platformy by měla být záměrným krokem, ne důsledkem změny v adresáři.

Část, kterou většina institucí přeskakuje: odebírání přístupu

Schémata oprávnění se navrhují při spuštění a poté se do nich už jen přidává. Přístup se hromadí: studentský výpomocník, který vystudoval, pracovník, který přešel na jinou fakultu, agentura, která web postavila před třemi lety. Každý z těchto účtů je stále cestou dovnitř.

Univerzita má zvláštní verzi tohoto problému, protože fluktuace je sezónní a předvídatelná. Studentský personál se mění každý semestr. Akademické administrativní funkce se obměňují ročně. Katedry se slučují. Nic z toho nevygeneruje pro webový tým žádné upozornění.

Většinu rizika pokrývají tři návyky.

• Propojte deaktivaci s identitním systémem. Pokud jsou účty vytvářeny na základě adresáře a role se přepočítávají při každém přihlášení, osoba, která přijde o adresářovou skupinu, ztratí práva k úpravám, aniž by kdokoli musel podávat žádost.
• Revidujte role podle akademického kalendáře, ne podle náhodně zvoleného data. Kontrola na začátku každého semestru zachytí obměnu studentů, dokud je změna ještě aktuální.
• Účty raději blokujte, než abyste je mazali. Blokování odebere přístup, ale zachová autorství, takže historie o tom, kdo co napsal, přežije.

Krátký seznam osob, které mají role administrátora platformy a centrálního editora, revidovaný jednou za semestr jmenovitě určenou osobou, má větší cenu než jakékoli množství procesní dokumentace.

Osobní údaje a vrstva oprávnění

Jakmile web obsahuje přihlašovací formuláře, registrace na akce nebo studentské záznamy převzaté z jiného systému, stává se schéma oprávnění nástrojem ochrany dat, nikoli jen redakčním usnadněním.

Ve Spojených státech zákon FERPA rozlišuje mezi vzdělávacími záznamy a adresářovými informacemi a rozhodnutí o tom, která pole spadají do které kategorie, přísluší studijnímu oddělení (registrar), nikoli webovému týmu. V Evropské unii a Spojeném království směřuje stejným směrem princip minimalizace údajů v GDPR: lidé by se měli dostat pouze k datům, která jejich práce vyžaduje, a ne více.

Z toho plynou tři praktické body. Kontrola oprávnění na úrovni pole umožňuje formuláři sbírat pole, které si většina editorů nemůže zpětně přečíst, což je správné řešení pro kontaktní údaje v dotazníkovém formuláři. Přístup k odeslaným datům formuláře by měl být samostatnou rolí oddělenou od možnosti upravovat stránku, na které formulář je, protože osoba, která spravuje stránku studijního programu, přijaté přihlášky zpravidla nepotřebuje. A oprávnění prohlížet nepublikovaný obsah je širší, než se zdá, protože koncepty (drafty) často obsahují přesně ten materiál, který ještě nebyl schválen ke zveřejnění.

Revize a testování schématu oprávnění

Schéma oprávnění je konfigurace, což znamená, že jej lze exportovat, revidovat stejným způsobem jako kód a nasazovat, místo aby se klikáním upravovalo přímo na ostrém webu. Instituce, které k tomu takto přistupují, dokážou i po měsících odpovědět na otázku, co se změnilo a kdy.

Testování je krok, který se obvykle přeskočí. Jedinou spolehlivou kontrolou je mít testovací účet pro každou roli, přihlásit se pod ním a zkusit dělat věci, které by daná role dělat neměla. Čtení stránky s oprávněními vám řekne, co jste nastavili; používání účtu vám řekne, co jste skutečně vytvořili. Vyplatí se na platformě uchovávat jeden nečinný testovací účet pro každou roli přesně pro tento účel.

Jednu hranici stojí za to jasně pojmenovat, protože působí zmatky. Oprávnění určují, co smí daná osoba dělat. Redakční workflow určuje, v jakém stavu se daný obsah nachází a kdo jej posouvá do dalšího stavu. To, že přispěvatel může vytvořit stránku, ale nemůže ji publikovat, je rozhodnutí o oprávnění; to, že stránka zůstává v recenzi, dokud ji editor neschválí, je rozhodnutí o workflow. Obojí funguje společně a druhé jsme popsali v článku Schvalovací workflow obsahu pro univerzity.

Plánování vaší struktury rolí

Práce, která rozhoduje o tom, zda schéma oprávnění obstojí, není konfigurace. Je to rozhodnutí, které jednotky vlastní které části webu, kdo smí publikovat bez schválení, které role si fakulta může sama přiřazovat a co se stane, když někdo odejde. Tyto odpovědi přicházejí od instituce a Drupal je následně vynucuje.

Rozumný postup je nejprve zmapovat stávající vlastnictví obsahu, poté definovat nejmenší sadu rolí, která pokryje danou práci, přidat hierarchii sekcí, aby se tyto role uplatňovaly jen v rámci jednotky, delegovat dvě nejnižší role na fakulty, propojit přiřazování s identitním systémem a stanovit datum revize v akademickém kalendáři ještě před spuštěním platformy, ne až po něm.

Platformy na Drupalu, které tým Drupal4edu ve společnosti Drupart postavil pro instituce jako Sabancı University, METU a Yıldız Technical University, jsou navrženy přesně kolem této vrstvy, kdy malý centrální tým udržuje platformu konzistentní, zatímco každá fakulta si upravuje vlastní stránky. Více o našem přístupu si můžete přečíst na stránce Drupal pro vzdělávání.

Často kladené otázky o rolích a oprávněních v Drupalu

Poslední aktualizace: 18.09.2026 15:58