Właściciel zadania

Przeczytasz w 10 min.

Spis treści

1. Streszczenie
2. Koncepcja
3. Przypadek biznesowy
4. Budowa rozwiązania
5. Testy
6. Akcja przypisywania zadań
7. Do zapamiętania
8. Patrz także

Streszczenie

W artykule opisano funkcję właściciela zadania, która może być przydatna w zarządzaniu przetwarzaniem dokumentów w procesie, np. przez:

• dystrybucję zadań wśród użytkowników,
• zapobieganie podejmowaniu tego samego dokumentu przez kilku użytkowników jednocześnie,
• filtrowanie list dokumentów według właścicieli.

Wyznaczanie właściciela zadania w nAxiom odbywa się w aplikacji FrontSPA i jest możliwe na dwa sposoby: przy użyciu systemowej kontrolki w nagłówku formularza lub za pomocą akcji.

Koncepcja

W nAxiom zadanie to czynności wykonywane w odniesieniu do dokumentu biznesowego w określonym statusie. Przejście do kolejnego statusu oznacza zakończenie jednego zadania i rozpoczęcie następnego. Właściciel zadania to użytkownik przypisany do dokumentu w określonym statusie. Przypisanie staje się nieaktywne po zmianie statusu. Jeśli workflow przewiduje możliwość powrotu dokumentu do statusu z przeszłości, właściciel przypisany w tym statusie będzie znowu aktywny.

Właściciela zadania można zmienić oraz usunąć.

Przypadek biznesowy

Rozważmy proces biznesowy, w którym zamawiający składają zamówienia w systemie dostawcy. Proces obejmuje następujące kroki:

• Zamawiający wprowadza dane zamówienia, zapisuje je i zmienia status zamówienia na Utworzone
• Kierownik sprawdza zamówienie i zmienia status na W toku
• (opcjonalnie) Kierownik przypisuje właściciela zadania (status pozostaje bez zmian)
• Magazynier podejmuje zadanie przypisane przez kierownika (lista Moje zdania) lub przypisuje sobie zamówienie z listy Nieprzydzielone zadania
• Magazynier realizuje zamówienie i zmienia jego status na Zrealizowane

Ponieważ w tym procesie są używane uprawnienia ACL dla dokumentu biznesowego, przypisanie siebie jako właściciela zadania wymaga uprawnień do modyfikacji dokumentu (U) w danym statusie, a usunięcie właściciela i przypisanie dowolnego użytkownika jako właściciela wymaga uprawnienia do administrowania uprawnieniami (A). Schemat uprawnień przedstawia tabela poniżej:

	Utworzone	W toku	Zrealizowane
Twórca dokumentu	RUD*	R	R
Kierownik	RU	RA	R
Realizator (właściciel zadania)	-	RU	R

^{* R - odczyt, U - aktualizacja, D - usuwanie, A - administrowanie}

Budowa rozwiązania

Aktywowanie funkcji właściciela zadania wymaga włączenia przełącznika Pokazuj właściciela zadania w sekcji Metryka dokumentu na panelu właściwości sekcji toolbar formularza. Odpowiednie ustawienia przedstawiono na ilustracji poniżej.

Włączanie kontrolki do zmiany właściciela

Wygląd kontrolki po stronie FrontSPA pokazano na następnej ilustracji. Jest to lista rozwijana, z której można wybrać polecenia:

• Przejmij zadanie: przypisuje jako właściciela zadania bieżącego użytkownika;
• Przekaż do puli: usuwa użytkownika przypisanego jako właściciel zadania, zadanie pozostaje nieprzypisane;

Ponadto na liście znajduje się pole tekstowe, w które należy wpisać pierwsze trzy znaki nazwy użytkownika, aby wyświetlić listę podpowiedzi i wybrać nowego właściciela zadania.

Kontrolka do zmiany właściciela

Dodatkowo, potrzebne jest zdefiniowanie szablonów ustawień dla statusu W toku.

Szablony uprawnień dla statusu W toku

Do pełnej realizacji rozwiązania konieczne jest utworzenie dwóch widoków listowych oparte na poniższych zapytaniach. W ramach obsługi funkcji właściciela zadania widok SQL, który jest źródłem danych dla listy tworzonej przez flow, zawiera kolumnę TaskOwner z danymi właściciela zadania.

Zapytanie dla listy Nieprzydzielone zadania:

SELECT document.*
FROM [Ord_View]({@_LangId}) as document
WHERE TaskOwner IS NULL AND StatusName = 'W toku'

Zapytanie dla listy Moje zadania (wymagane połączenie z tabelami TaskOwnerships i UserProfiles, aby umożliwić filtrowanie według zalogowanego użytkownika {@_UserId}.

SELECT document.*
FROM [dbo].[Ord_View]({@_LangId}) as document
LEFT JOIN [core].[TaskOwnerships] o
  on o.RecordGuid = document.ACLId
     AND document.Status = o.StatusId
LEFT JOIN [core].[UserProfiles] up
  on up.Id = o.UserId
WHERE o.UserId = {@_UserId}

Dla tych widoków trzeba zdefiniować pozycje menu i nadać do nich uprawnienia odpowiednim rolom.

Testy

Ze względu na zmianę szablonu uprawnień działanie rozwiązania trzeba testować na nowych dokumentach.

Nowe zamówienia w statusie W toku będą widoczne na liście Nieprzydzielone zadania. Kierownik sprzedaży będzie mógł przydzielać te zadania poszczególnym magazynierom. Na liście Moje zadania magazynierzy będą widzieć tylko te zadania, do których są przypisani jako właściciele. Będą również mogli podejmować zadania z listy Nieprzydzielone zadania oraz zwracać do puli zadań nieprzydzielonych swoje zadania. Nie będą mogli przypisywać swoich ani nieprzydzielonych zadań innym użytkownikom.

Akcja przypisywania zadań

Właściciela zadania można wyznaczyć również przy użyciu akcji przypisywania zadań. Zapytanie SQL dla tej akcji musi zwracać identyfikator użytkownika oraz parametr, decydujący, czy właściciel ma zostać przypisany także wtedy, kiedy zadanie ma już przypisanego właściciela. W oknie dialogowym definiowania akcji znajduje się odpowiednia instrukcja wraz z przykładem.

Akcja przypisywania zadań

W opisanym przykładzie przypisanie właściciela zadania przez kierownika można wykonać, za pomocą akcji przypisania zadania użytej jako Akcja uruchamiana po dla przejścia do statusu W toku. Kierownik będzie tylko wcześniej musiał wskazać użytkownika.

• Uruchomienie akcji dla dokumentu bez statusu (nowy) jest ignorowane; brak wpisu w tabeli TaskOwnerships, brak komunikatu o błędzie.
• Akcja przypisuje właściciela zadania do dokumentu w bieżącym statusie.
• Akcja przypisuje właściciela zadania do bieżącego dokumentu.
• Po zmianie właściciela zadania za pomocą akcji, odśwież formularz, aby wyświetlić dane właściciela w nagłówku formularza.

Do zapamiętania

• Standardowe metody pozwalają wyznaczyć właściciela zadania tylko z poziomu formularza i tylko dla bieżącego dokumentu wyświetlanego w formularzu.
• Możliwe jest użycie samodzielnie napisanych zapytań, które będą zapisywać i aktualizować dane w tabeli TaskOwnerships i w ten sposób wyznaczać właścicieli dla dowolnych dokumentów i w dowolnym statusie.
• Użytkownik jest właścicielem zadania tylko w statusie, w którym został przypisany; przejście do kolejnego statusu wymaga przypisania nowego właściciela.
• Zmiana statusu nie powoduje usunięcia rekordu z tabeli TaskOwnerships, dlatego jeśli workflow procesu przewiduje możliwość powrotu do statusu, w którym był wyznaczony właściciel, dokument w tym statusie będzie miał tego samego właściciela.
• Właściciela zadania można zmienić lub usunąć.
• Do usunięcia oraz zmiany właściciela wymagane są uprawnienia do administrowania uprawnieniami dla dokumentu (A).
• Do przypisania siebie jako właściciela zadania wystarczy uprawnienie do modyfikacji dokumentu (U).

Patrz także

• Artykuł z Bazy Wiedzy nr 1. Szablony uprawnień ACL
• Leksykon nAxiom: 4.5.14. Akcje przypisywania zadań
• Leksykon nAxiom: 5.8 Uprawnienia do dokumentów (CRUD/A)