W dzisiejszym poście pokażę Wam jak w elastyczny sposób ograniczyć możliwość edycji zadań i pól do konkretnej grupy użytkowników. A to wszystko bez użycia pluginów. Wykorzystamy jedynie wbudowane mechanizmy Jira, np. Security Schemes czy Workflow Conditions. Zaczynamy!

Potrzeba biznesowa brzmi: należy ograniczyć możliwość przeglądania i edycji zadań do wybranej grupy osób. Dodatkowo grupa ta powinna być definiowana osobno dla każdego zadania w projekcie. Oprócz tego rola Support Team powininna mieć dostęp do wszystkich zadań w projekcie. Poniżej elementy, które potrzebujemy skonfigurować. Wszystkie nazwy własne są oczywiście umowne, możecie użyć dowolnych innych. Pamiętajcie, że menu administratora można wywołać skrótem gg).

1. utworzenie nowej roli o nazwie Support Team

• gg -> Project Roles -> Add Project Role
• do realizacji zadania można wykorzystać również jedną z istniejących ról
• osoby w tej roli będą obsługiwać projekt, należy więc odpowiednio dostosować uprawnienia (Permission Scheme)

2. utworzenie nowego pola typu User Picker (multiple users) o nazwie Members

• gg -> Custom fields -> Add custom field
• docelowo użytkownicy dodani do tego pola będą mogli przeglądać i edytować dane zadanie
• pole będzie mogło być uzupełniane jedynie przez osoby będące w roli Support Team w danym projekcie

3. dostosowanie Permission Scheme tak, aby uprawnienia Browse Issues oraz Edit Issues mieli wszyscy zalogowani użytkownicy (Any logged in user)

• należy pamiętać o nadaniu osobnych uprawnień dla roli Support Team oraz grupy jira-administrators
• uprawnienie będzie dalej ograniczone przez Security Level

4. utworzenie Issue Security Scheme oraz Security Level o nazwie Edit Issue Restriction

• gg -> Issue Security Schemes -> Add issue security scheme
• w konfiguracji ustawiamy aby dostęp do zadań mieli jedynie użytkownicy będący w polu Members, czyli User custom field value – Members
• dodajemy tu również Project Role – Support Team oraz Group – jira-administrators
• ustawiamy utworzony Security Level jako domyślny (default)

W tym momencie każde nowe zadanie otrzyma Security Level = Edit Issue Restriction, co pozwoli na przeglądanie zadań przez Support Team, administratorów Jira oraz osoby dodane do pola Members, które nie jest jeszcze na żadnym z ekranów. Pora na dalszą część konfiguracji. Na potrzeby zadania zakładamy, że w projekcie jest tylko jeden typ zadań i jeden odpowiadający mu workflow.

5. utworzenie nowego ekranu o nazwie Modify Members Screen, do którego dodajemy pole Members

• pole Members powinno znaleźć się jedynie na w/w ekranie, należy je w miarę potrzeby usunąć z pozostałych ekranów (create, view, edit screens)

6. zmodyfikowanie Workflow

• na kroku In Progress dodajemy tranzycję Modify Members do prowadzącą z powrotem do In Progress
  
  
• do tranzycji dodajemy utworzony wcześniej Modify Members Screen
  
• należy zwrócić uwagę czy Workflow nie jest współdzielony z innymi projektami
• dodatkowo, jeśli edytujemy aktywny workflow to po wprowadzeniu zmian należy go jeszcze opublikować

Teraz pole Members może być edytowane jedynie przy pomocy dodanej właśnie tranzycji. Należy jeszcze ograniczyć dostęp do niej tylko dla osób w roli Support Team.

7. utworzenie Workflow Condition typu User is in Project Role Condition i ustawienie roli Support Team

I tyle. Od teraz nowe zadanie będzie widoczne i edytowalne jedynie dla zespołu Support Team, administratorów Jira oraz osoby będące w polu Members. Pole Members można uzupełnić tylko poprzez tranzycję Modify Members. Z kolei tranzycja widoczna jest jedynie dla osób z Support Team. Rozwiązanie możemy wdrożyć zarówno dla wersji Cloud jak i Server, bez konieczności użycia zewnętrznych pluginów. Powodzenia w testowaniu i wdrażaniu rozwiązania!

Masz pytania? Chcesz podzielić się wiedzą, doświadczeniem? Zapraszam do komentowania oraz do kontaktu na contact@jiraforthepeople.com