Dostępne walidatory

Walidator, na podstawie podanego loginu, wyszukuje użytkownika i zapisuje zdefiniowaną informację o jego istnieniu/nieistnieniu do podanej zmiennej.

Login : STRING

Login sprawdzanego użytkownika.

Tylko aktywny : BOOLEAN

Flaga informująca o tym, czy wyszukiwany użytkownik musi znajdować się na liście aktywnych użytkowników.

Informacja o niewystępowaniu : STRING

Informacja zapisywana do zmiennej w przypadku nieistnienia w systemie użytkownika o podanym loginie.

Potwierdzenie : BOOLEAN

Informuje o tym, czy wyświetlić okienko potwierdzenia.

Komunikat : STRING

Treść komunikatu w oknie z błędem/oknie potwierdzenia.

Na podstawie loginu i id roli z procesu walidator ustala czy użytkownik posiada podaną rolę.

Login użytkownika : STRING

Login użytkownika, dla którego sprawdzane jest posiadanie roli.

Id roli : STRING

Id roli z mapy określonego procesu.

Szukać w pakiecie? : BOOLEAN

Określa, czy rola ma być wyszukiwana w obrębie pakietu, a nie tylko obecnego procesu.

Potwierdzenie : BOOLEAN

Informuje o tym, czy wyświetlić okienko potwierdzenia.

Komunikat : STRING

Treść komunikatu w oknie z błędem/oknie potwierdzenia.

Sprawdza, czy podłączono dokument/y na zasadach określonych przez parametry.

Klasy dokumentów : STRING_ARRAY

Opc. nazwy klas dokumentów. Komponent dostarcza rozwijalną listę nazw klas.

Podłączono tutaj? : BOOLEAN

Decyduje o tym, czy szukane dokumenty miałyby być podłączone w obecnym zadaniu.

Komunikat : STRING

Treść alertu

Potwierdzenie : BOOLEAN

Decyduje o tym, czy okienko informujące o błędzie zastąpić okienkiem potwierdzenia (dla wartości true).

Przyjmuje wynik funkcji podanej w parametrze, która ewaluuje dane pod względem prawidłowości. Jeżeli funkcja logiczna zwróci prawdę, to walidator przechodzi dalej. Jeżeli zwróci fałsz, to pokaże komunikat.

Update:

W walidatorze istnieje możliwość walidowania tabel dynamicznych. Aby zwalidować tabelę należy określić, czy sprawdzanie warunku ma się odnosić do każdego wiersza w tabeli, czy też dowolnego wiersza w tabeli.
Przykład 1. Chcę, aby tabela posiadała PRZYNAJMNIEJ JEDEN wpis, gdzie w kolumnie "uzytkownik" wpisana jest nazwa aktualnego użytkownika.

Przykład 2. Chcę, aby formularz przepuszczał użytkownika dalej jedynie w przypadku, gdy WSZYSTKIE wiersze w kolumnie "zadluzenie" są równe 0.

Pierwszym krokiem jest wybranie odpowiedniej wartości z parametru: "Użycie tabeli w funkcji". Dla przykładu pierwszego będzie to "Funkcja z użyciem kolumn(jakikolwiek wiersz)", dla przykładu drugiego "Funkcja z użyciem kolumn(każdy wiersz)".

UWAGA: Zmienne "Każdy wiersz" i "Jakikolwiek wiersz" nie mogą zostać użyte razem w funkcji walidującej. Pomimo pojawiania się obu z nich w menu wyboru zmiennej to tylko zmienna wybrana w parametrze "Użycie tabeli w funkcji" będzie działać poprawnie.

Po wybraniu odpowiedniego parametru możemy użyć następującego zestawu funkcji:

Dla przykładu 1: eq(item($Jakikolwiek wiersz, $uzytkownik), $aktualny_uzytkownik)

Gdzie: $Jakikolwiek wiersz to zmienna kontekstowa(powinna się pojawić po wpisaniu dolara), $użytkownik to zmienna kolumnowa, którą chcemy sprawdzić, a $aktualny_użytkownik to zmienna przetrzymująca login aktualnego użytkownika.

Dla przykładu 2: eq(item($Każdy wiersz, $zadluzenie), 0)

Gdzie: $Każdy wiersz to zmienna kontekstowa(powinna się pojawić po wpisaniu dolara), a $zadluzenie to zmienna kolumnowa, którą chcemy sprawdzić

Funkcja : FUNCTION

Funkcja zwracająca wynik typu logicznego.

Potwierdzenie : BOOLEAN

Decyduje o tym, czy okienko informujące o błędzie zastąpić okienkiem potwierdzenia (dla wartości true).

Komunikat : STRING

Treść alertu

Użycie tabeli w funkcji : STRING
Określa czy, i w jaki sposób użyć wartości kolumn z tabeli dynamicznej

Długość tabeli : INTEGER

Liczba wierszy w tabeli(można uzyskać przekazując długość dowolnej z kolumn tabeli)

Na podstawie zestawu zmiennych sprawdza, czy w systemie istnieją już inne procesy zawierające te same wartości przechowywane przez te zmienne.

Update 139:

Komunikat posiada wbudowany interpreter, dzięki któremu możemy się odwołać do kontekstu zduplikowanego procesu. Możemy zatem pobrać zmienne ze zduplikowanego procesu, podając w umieszczając w komunikacie id zmiennej między dwoma znakami "@". Przykład:

Treść alertu: "Zduplikowany proces posiadał wniosek o id: @id_wniosku@." - w miejsce @ id_wniosku@ zostanie wpisana wartość zmiennej o id: "id_wniosku" ze zduplikowanego procesu.

Zmienne : VARIABLE_ARRAY

Wybrane zmienne procesu

Potwierdzenie : BOOLEAN

Decyduje o tym, czy okienko informujące o błędzie zastąpić okienkiem potwierdzenia (dla wartości true).

Komunikat : STRING

Treść alertu

Zmienne wykluczająca potencjalne duplikaty : VARIABLE_ARRAY

Zmienne, które wartości z poniższego parametru wyklucza dany proces z ewaluacji.

Wartości dla zmiennych wykluczającej : STRING_ARRAY

Tablica wartości, z których każda decyduje o wykluczeniu potencjalnego duplikatu z ewaluacji.

Rodzaje procesów : STRING

Wybieramy, w jakich procesach szukać duplikatu: otwarte, zamknięte lub wszystkie.

Weryfikuje podane warunki i wyświetla odpowiedni komunikat jeżeli weryfikacja została zakończona niepowodzeniem.

Szczegółowe dane odnośnie konfiguracji: http://192.168.1.52:8081/confluence/display/CUF/DocumentService

(Weryfikacja dokumentów procesu(od 3.1.3-0))

Tryb weryfikacji : STRING (lista wartości)

Określa w jaki sposób weryfikować dokumenty podłączone do procesu. Dostępne są trzy tryby - activity, stage i process.

Wyświetlanie komunikatu : BOOLEAN

Decyduje o tym, czy wyświetlać komunikat. Domyślnie TRUE.

Warunki : STRING_ARRAY

Lista warunków do spełnienia przez weryfikowane dokumenty. Warunki zostały opisane w artykule przedstawiającym szczegóły konfiguracji. Należy jednak pamiętać, że implementacja rozwiązania w walidatorze zakłada, że warunki deklarowane są bez użycia apostrofów! Przykładowy warunek: conditionType:<=

Potwierdzenie : BOOLEAN

Decyduje o tym, czy okienko informujące o błędzie zastąpić okienkiem potwierdzenia (dla wartości true).

Wyświetla okno z możliwością podania komentarza w przypadku braku komentarza od użytkownika

Walidator sprawdza istnienie wpisu w bazie danych (np. może sprawdzić, czy istnieje użytkownik o danym id). Następnie sprawdza, czy wpis ten posiada te same wartości, które znajdują się na formularzu (możemy sami zdecydować, które wartości ma porównać).

Mogą wystąpić trzy możliwości:

• wpis nie istnieje, a użytkownik może dodać nowy wpis w bazie, wtedy pojawia się okno dodania nowego wpisu
• wpis istnieje, ale z innymi danymi - wtedy użytkownik może edytować dane - pojawia się okno akceptacji zmian
• wpis istnieje, z identycznymi danymi - wtedy walidator przechodzi dalej

W oknie dodania/edycji istnieje możliwość pominięcia walidacji i przejścia dalej.

Aby walidator działał poprawnie, musimy przygotować odpowiednie zapytania w bazie danych, które będą wywoływane podczas sprawdzania istnienia/identyczności/dodawania/edycji danych. W tym celu należy dodać cztery zapytania do tabeli pm_dbqueries, pamiętając o dodaniu odpowiedniego identyfikatora.

Przykład: Załóżmy, że chcemy sprawdzić, czy istnieje użytkownik, którego dane są zapisane na formularzu. Przykładowe wpisy w pm_dbqueries mogłyby wyglądać tak:

W tym przykładzie nasz klucz zapytania to USER. Do klucza zapytania musimy dodać frazy: _EXIST, _EQUALS, _INSERT bądź _UPDATE, by określić ich przeznaczenie. Parametry oznaczone znakiem zapytania możemy dodać w konfiguracji walidatora(należy pamiętać o kolejności! w ostatnim zapytaniu identyfikator wiersza pojawia się na końcu!)