Ustawienia: Operator / Grupa/ Wszyscy

0

Dla rozgrzewki:
Typowy system autoryzacji, oparty na Rolach, w tym poście będe trochę mieszał z Grupą. Operator ma sumę logiczną zbioru praw, z Ról do jakich należy *) To jest genberalnei przyjęte, i trudno o tym dług gadać.
Np na mocy roli/prawa mogę z prawem "prawo do cen zakupu" związać pola "cena zakupu PLN", "cena zakupu USD"

A teraz ustawienia (w obrębie limitu praw oczywiście):
Kazik jest w grupie "senior sprzedawca" (na kraj), i MOŻE widzieć oba pola, ale czy musi widzieć pole w USD? Chciałby to sobie wyłączyć, np aby oszczędzić miejsce na gridach.
Zenek jest w grupie "import". Ma uprawnienie do obu pól, i pole w USD jest jego codziennym narzędziem pracy.

Myslę o defaultowym ustawieniu dla grup "import" -> widoczne pole "zakup w USD". Tylko że Zenek należy też do sprzedaży, i inna grupa będzie proponowała niewidoczność tego pola.
W dziedzinie autoryzacji jest prościej, suma logiczna itd i mamy rozstrzygnięte.

Ustawienia Wszyscy -> Grupa(y) -> Operator, moga już siedzieć w bazie z etapu wdrożenia, lub być nowe, np nowa wersja może przynieśc pole "kurs zakupu podczas importu", i żeby temu polu dać defaultowe widoczności dla grup (a nie musieć szkolić ludzi, pisać maili "możecie sobie ustawić widoczosc nowego pola Xyz" )

Czy w moim myśleniu są wady? czy mam zupełnie rozdzielić Role autoryzacyjne / Grupy ustawieniowe ? W małym / średnim biznesie nie chciałbym adminowi wdrożenia dawać komplikacji intelektualnych

A może Grupa (obiektowo biorąc) ma być encją jednego z dwóch typów GrupaWyłączna / GrupaPosiadającaAlternatywę, jedna może być nośnikiem ustawień, druga nie ???

Nie pytam głownie o szczegóły implementacji, tylko o zdrowe zaprojektowanie

*) zakładam, że oprócz pozytywnych praw, nie ma negatywnych zakazów, byłby to gest rozpaczy projektanta.

1

Rozumiem tak:
Grupa = {User#1, ..., User#N}
User-> Rola#1, Rola#2, ..., Rola#N
Rola#X - Uprawnienie#1, ..., Uprawnienie#N
Widok#X = Pole1,...,PoleN
Pole#X - uprawnienie#Z#read, uprawnienie#Z#write (tu sobie wymyśliłem, że w takim systemie rozdrobnionym uprawnienie mogą mieć flagi typu C,R,U,D)

Głupie pytanie, ale co stoi na przeszkodzie dostrugać funkcjonalność "Dostosuj widok", która pozwala użytkownikowi ukrywać niechciane pola widoku?

Wówczas domyślna konfiguracja wdrożeniowa odciążyłaby wdrożeniowca/admina, a dla użytkowników złaknionych luksusu -> "Dostosuj widok".
Wyświetlane pola: Suma logiczna uprawnień przecięta z polami minus ustawienia użytkownika "dostosuj widok".

0
yarel napisał(a):

Głupie pytanie, ale co stoi na przeszkodzie dostrugać funkcjonalność "Dostosuj widok", która pozwala użytkownikowi ukrywać niechciane pola widoku?

Wówczas domyślna konfiguracja wdrożeniowa odciążyłaby wdrożeniowca/admina, a dla użytkowników złaknionych luksusu -> "Dostosuj widok".
Wyświetlane pola: Suma logiczna uprawnień przecięta z polami minus ustawienia użytkownika "dostosuj widok".

Oczywiście mowa o funkcji "dostosuj widok", tylko z propozycją początkową.

Ponieważ dokumentacja / komuniakcja zawsze jest w tyle za kodem, widze w tym tani spsoób dodawania np nowych pól do widoku.
Np ktoś był nieobecny podczas wizyty wdrożeniowca z nową wersją, i nigdy nie został poinformowany o możliwości.

A fukcja "dostosuj widok" by miała podmenu "Dodaj proponowane pola"

1 użytkowników online, w tym zalogowanych: 0, gości: 1