Walidatory ukończone
| Nazwa | Kategoria | Stan | Dostępne od wersji | Opis | Parametry | |
|---|---|---|---|---|---|---|
| Sprawdzenie istnienia użytkownika | Użytkownik | | JIRA | | server | 192.168.1.52 JIRA||
| serverId | 2e6b42a8-62e1-3c71-bfe9-dbf183b33dc1 | |||||
| key | CUFCMP-68 | | Expand | | |||
|
| > Szczegółowy opis < | ||||
| Walidacja posiadania roli przez użytkownika | Użytkownik | | JIRA | | server | 192.168.1.52 JIRA||
| serverId | 2e6b42a8-62e1-3c71-bfe9-dbf183b33dc1 | |||||
| key | CUFCMP-5 | | Expand | | |||
|
| > Szczegółowy opis < | ||||
Walidacja podłączenia dokumentów | Dokumenty | | JIRA | | server | 192.168.1.52 JIRA||
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution | |||||
| serverId | 2e6b42a8-62e1-3c71-bfe9-dbf183b33dc1 | |||||
| key | CUFCMP-21 | | Expand | | |||
|
| > Szczegółowy opis < | ||||
| Walidacja na podstawie logicznego wyniku funkcji | Ogólne | | JIRA | | server | 192.168.||
| serverId | 2e6b42a8-62e1-3c71-bfe9-dbf183b33dc1 | |||||
| key | CUFCMP-8 |
| JIRA | ||||||
|---|---|---|---|---|---|---|
|
1.0.0
1.0.10
| title | Opis |
|---|
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ć
| Expand | ||
|---|---|---|
| ||
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 Długość tabeli : INTEGER Liczba wierszy w tabeli(można uzyskać przekazując długość dowolnej z kolumn tabeli) |
> Szczegółowy opis <
Walidacja unikatowości procesu
Ogólne
| JIRA | ||||||
|---|---|---|---|---|---|---|
|
| JIRA | ||||||
|---|---|---|---|---|---|---|
|
| title | Opis |
|---|
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.
| Expand | ||
|---|---|---|
| ||
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. |
| title | Opis |
|---|
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))
| Expand | ||
|---|---|---|
| ||
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: Potwierdzenie : BOOLEAN Decyduje o tym, czy okienko informujące o błędzie zastąpić okienkiem potwierdzenia (dla wartości true). |
| title | Opis |
|---|
Wyświetla okno z możliwością podania komentarza w przypadku braku komentarza od użytkownika
| title | Opis |
|---|
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:
| name | query |
|---|---|
| USER_EXIST | SELECT * FROM pm_cust_users WHERE userid = ? |
| USER_EQUAL | SELECT * FROM pm_cust_users WHERE userid = ? AND name = ? AND username = ? |
| USER_INSERT | INSERT INTO pm_cust_users (userid, name, username) VALUES (?, ?, ?) |
| USER_UPDATE | UPDATE pm_cust_users SET name = ? , username = ? WHERE userid = ? |
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!)
| Expand | ||
|---|---|---|
| ||
> Szczegółowy opis <