Dobrý deň.
Bolo by možné doplniť možnosť nastavenia skupín oprávnení / rolí, ktoré by sa prideľovali užívateľom? Užívateľom by sa dalo priradiť aj viacej rolí. Významne by to zjednodušilo nastavovanie oprávnení pri komplexných dispečingoch s veľkým množstvom modulov, funkcií a užívateľov.
Aktuálne je nastavenie príliš pracné a to vedie k zjednodušovaniu alebo obchádzaniu adresných - menných užívateľov.
Dobry den.
Neviem ci rozumiem. Ale ak rola=skupina objektov, tak uzivatelovi viem nastavit viacero rolí teda skupin objektov.
Dakujem.
Rolu treba chápať ako niekoľko (aj 30 a viac) skupín objektov s rôznymi úrovňami oprávnenia. Tiež ak potom vytváram nad nimi 50+ užívateľov, tak to je dosť klikania. Nehovoriac o tom, že keď to mám po sebe skontrolovať, pridať nejaké nové skupiny len určitej role a nepomýliť sa, tak je to fuška. Spraviť jednu úpravu nejakej roly je aktuálne v niektorých prípadoch na úpravu desiatok užívateľov. Ak by na to bola rola (skupina nastavení oprávnení k určitým skupinám objektov), tak to mám na pár klikov. Ak už by som mal nastavené roly, tak rozšíriť nejakého užívateľa o novú rolu, by bolo len o priradení ďalšej roly.
Rozumiem.
A nasmerovali ste ma na dobre vylepsenie ktore pokryje aj vas use case.
Vylepsenie bude take, ze dovolim uzivatelovi (v jeho konfiguracii) do zoznamu skupin objektov priradit aj ineho uzivatela. Sposob priradenia (Read, Control Modify, None) v tomto pripade nebude mat zmysel.
Fungovat to bude tak, ze vysledny zoznam skupin pre uzivatela sa rozsiri aj o zoznam skupin ktore ma uzivatel, ktory bol zaradeny medzi skupiny (v podstate je to uzivatel typu rola).
Priklad:
Uzivatel “rola_dispecer” ma priradene skupiny A-Read, B-Control
Uzivatel “dispecer” ma priradene skupiny C-Read, rola_dispecer-pristup nie je zaujmavy
Vysledok bude taky, ze uzivatel “dispecer” bude mat skupiny C-Read, A-Read, B-Control
V podstate to bude fungovat ako #include <>.
Napad zaradim do planu vyvoja pre dalsiu verziu V22.
Dobrý deň.
Ešte by sa zišlo, keby priradenie ku skupine objektov (teda roly) boli podľa priority tak, že čím špecifickejšie je v skupine objekt definovaný, tým má vyššiu prioritu pre objekt celá skupina. Ak dám napr. proces SELF.ALA aj s potomkami do skupiny, ktorá bude mať práva None, už nikdy neviem vybrať konkrétny alarm z toho procesu, aby mal iné práva ako None (keďže priority sú None - Modify - Control - Read). Povedzme, že chcem zakázať zobrazenie všetkých alarmov a potom iba niektoré vyberiem, ktoré sa majú zobrazovať.
Príklad:
- Proces [SELF.ALA] je v skupine Alarm_ALL aj s potomkami.
- Užívateľovi User nastavím Alarm_ALL na None.
- A.IO1_error je pod procesom SELF.ALA.
- A.IO1_error priradíme do skupiny UserAlarm.
- Skupinu UserAlarm priradím užívateľovi User s právami Control.
Výsledok: Užívateľ User neuvidí alarm A.IO1_error, lebo je pod skupinou Alarm_ALL (ako potomok, bez prístupu, najvyššia priorita) aj UserAlarm (napriamo, ovládanie).
Najskôr by sa malo brať, v ktorých skupinách je čo najviac špecifikovaný dotknutý objekt a až následne prioritizovať podľa úrovne prístupu len z vybraných skupín.
Obdobný príklad s viacerými úrovňami: SELF.KOM - L.Line1 - B.Station1 - B.Station1.PointName
Ďakujem.