Reguły szczegółowe służą do przygotowania różnych zestawów stron, pól i działań dla poszczególnych grup. Przykład: handlowcy edytują dane klienta, a inna grupa tylko je przegląda. Najpierw przeczytaj wprowadzenie i hierarchię pełnych praw oraz przygotuj grupy użytkowników.
1. Kiedy reguły są używane? #
Pełna grupa kartoteki ma pierwszeństwo przed ustawieniami strony. Pełna grupa strony ma pierwszeństwo przed regułami szczegółowymi. Jeżeli ustawiono pełną grupę, osoba spoza niej dostaje odmowę — nie przechodzi do reguł niższego poziomu.
Aby korzystać z reguł, w polu „Pełne uprawnienia dla grupy” kartoteki i odpowiedniej strony pozostaw wartość „Brak wyboru”. Nie wyłączaj pełnych praw bez przygotowania zastępujących je reguł. Narzędzia porządkowania konfiguracji mogą usuwać reguły zasłonięte pełnymi prawami; po zmianie trybu sprawdź rzeczywistą listę reguł.
2. Przyznaj stronę, pola i działania #
| Rodzaj reguły | Co przyznaje? |
|---|---|
| Wyświetlane strony | Możliwość otwarcia wskazanych stron. |
| Elementy formularza | Podgląd albo edycję wskazanych elementów. |
| Opcje zestawień | Dostęp do wskazanych działań lokalnego menu, np. dodawania lub zapisu. |
Reguła udostępniająca stronę nie udostępnia automatycznie jej pól i przycisków. Przygotuj potrzebne rodzaje reguł. Jedna reguła może obejmować kilka celów: wiele stron tej samej kartoteki albo wiele elementów/opcji jednej strony.
W trybie konstruktor otwórz konfigurację strony lub elementu. Dla elementu formularza rozwiń menu „Uprawnienia do elementu” i wybierz opcję menu „Uprawnienia do elementu formularza”. Otwórz regułę ikoną w kolumnie „Kartoteka”. W formularzu sprawdź pola „Dostęp do elementu formularza”, „Elementy formularza”, „Grupa użytkowników”, „Dodatkowy warunek” i „Wymagany w polu”.
3. Jak łączą się reguły? #
Pasujące reguły sumują dostęp do stron i opcji. Dla elementów formularza obowiązuje najwyższy poziom: podgląd lub edycja. Kolejność reguł nie rozstrzyga wyniku. Nie ma ogólnej reguły „zakaz”, która odbierałaby przyznanie pochodzące z innej grupy.
Przykład: pracownik należy do grup A i B. A daje podgląd pola, B edycję — pracownik uzyskuje edycję, z uwzględnieniem dodatkowych natywnych ograniczeń elementu, np. tylko do odczytu.
4. Warunki dotyczą bieżącego obiektu #
pole oznaczone atrybutem „Uwzględniaj w uprawnieniach i przy opcjach dodawania” może udostępniać wartości jako dodatkowe warunki. pole „Wymagany w polu” pozwala wskazać powiązanie z pracownikiem lub — w portalu — osobą klienta. Szczegóły: atrybuty pól.
Wartości w jednym warunku są alternatywami (LUB), a różne kategorie warunków muszą być spełnione łącznie (I). Warunki odnoszą się do bieżącego obiektu kartoteki. Gdy go nie ma, natywne sprawdzenie tych dodatkowych warunków jest pomijane.
Widoczność opcji „Usuń zaznaczone” nie oznacza sprawdzenia statusu każdego zaznaczonego dokumentu. Jeśli operacja może obejmować wiele rekordów, jej obsługa musi sprawdzić każdy z nich. trigger widoczności może dodatkowo ukrywać opcję, ale wynik true nie przyznaje brakujących praw grupowych.
5. Wspólna obsługa przez MCP #
- Odczytaj grupy komendą
bs4_list_permission_groupszinterface=internallubportal. - Odczytaj
bs4_get_access_configurationdlascope=cardalbopagei odpowiedniegoid. Sprawdź źródło pełnych praw i dostępnecondition_choices. - Wylistuj reguły przez
bs4_list_permission_rulesdlacard_id. poleshadowed_target_idswskazuje cele zasłonięte pełnymi prawami. - Użyj
bs4_create_permission_rule,bs4_update_permission_rulelubbs4_delete_permission_rule. Zmianę trybu wykonuje osobnebs4_update_access_configuration.
Reguła ma target_type: page, form_element lub page_menu_option, listę target_ids oraz user_group_id albo tekstowe portal_group_value. Dla formularza podaj form_access=view lub edit. W aktualizacji pominięte właściwości pozostają bez zmian; podanie target_ids zastępuje całą listę celów. Puste listy warunków usuwają warunek.
Warunki wybieraj wyłącznie spośród tokenów zwróconych przez condition_choices. Nie są to formuły SQL. Zapis domyślnie jest podglądem; wykonanie wymaga dry_run=false i operation_id.
6. Sprawdź wynik na zwykłym koncie #
bs4_explain_access wyjaśnia konfigurację grupową dla pracownika albo osoby portalu. Korzysta z zapisanych przypisań, nie z grup zapamiętanych w aktywnej sesji. Nie wykonuje triggerów, nie sprawdza całej operacji ani nie zastępuje testu użytkownika. Ustawienie complete_runtime_check=false jest celowe.
Po zmianie sprawdź otwarcie strony, podgląd, zapis oraz dostęp do danych na właściwym koncie. Superadministrator nie jest dobrym kontem do sprawdzania ograniczeń zwykłego pracownika.
Dalej: strony i uprawnienia portalu oraz ograniczenie danych klientów.
