Intro - Jira에서 필드(Field)와 스크린(Screen)

지난 포스트에서 Jira에서 스킴(Scheme)을 이야기해보았는데요. (Jira Schemes은 무엇일까? (1))
이때 필드 스킴, 스크린 스킴에 대해서 이야기를 하다가 필드와 스크린도 따로 이야기해보는 것이 좋을 것 같아 정리해보려고 합니다!

지난번에도 보았던 스크린과 스킴, 필드에 대한 구조도

Project screens, schemes and fields (EN)

지난 포스트에서도 한번 보았던 다이어그램입니다.
다이어그램을 보면 대략 알 수 있지만 정리해보면 다음과 같을 수 있겠네요.

필드 구조 특징

• 필드는 스크린에 들어갑니다.
• 필드 설정에 따라 필드를 안보이게 하거나, 필수 입력 값으로 설정할 수 있습니다.
  • 특정 필드가 필요하지 않다면 Hide 설정하여 보이지 않게 할 수 있습니다.
  • 특정 필드가 입력이 필요하다면 Required 설정하여 입력을 강제할 수 있습니다.
• 필드 설정은 필드 설정 스킴에서 이슈 타입에 따라 맵핑하여 사용할 수 있습니다.
  • 이슈 타입에 따라 필드 설정을 각각 다르게 설정할 수 있습니다.
  • 모든 이슈 타입에 대해 같은 필드 설정을 할 수 있습니다.
• 필드 설정 스킴은 프로젝트에 종속적입니다.

스크린 구조 특징

• 스크린은 필드를 가집니다.
• 스크린 스킴은 이슈의 조작(Operation)에 맞춰 설정할 수 있습니다.
  • 이슈 생성(Create)/수정(Edit)/보기(View)에 따라 각각의 스크린을 만들어 적용할 수 있습니다.
  • 각각의 스크린에 다른 필드들을 설정 가능하다는 것을 의미합니다.
• 스크린 스킴은 이슈 타입 스크린 스킴에서 이슈 타입에 따라 맵핑하여 사용할 수 있습니다.
  • 이슈 타입에 따라 스크린 스킴을 각각 다르게 설정할 수 있습니다.
• 이슈 타입 스크린 스킴은 프로젝트에 종속적입니다.

워크플로우(Workflow, 흐름) 구조 특징

필드와 스크린 내용에는 설명할 예정은 없었지만 구조도에 있기에 정리해봅니다.

• 워크플로우에서 상태 간의 트랜지션(이동)에 스크린을 맵핑할 수 있습니다.
  • 상태 변경 중에 스크린이 나타나고 특정 값을 변경하는 방식으로 설정이 가능합니다.
• 워크플로우는 워크플로우 스킴에서 이슈 타입에 따라 맵핑하여 사용할 수 있습니다.
  • 이슈 타입에 따라 워크플로우를 각각 다르게 설정할 수 있습니다.
• 워크플로우 스킴은 프로젝트에 종속적입니다.

구조도에 나온 내용은 이쯤에서 마무리하고 필드와 스크린 설명으로 넘어가겠습니다. :)

필드 (Field)

Jira에서 필드란 무엇일까요?
간단하게 생각해보면 이슈에서 필요한 정보를 담기 위한 변수라고 볼 수 있을 것 같습니다.
Jira 시스템 상에는 기본적으로 있는 시스템 필드가 있고 사용자가 필요시 만들어서 사용할 수 있는 커스텀 필드가 있습니다.

시스템 필드 (System Field)

Jira에서 기본적으로 제공하는 필드를 의미합니다. 어떻게 보면 시스템 필드라고 부르는게 정확한지는 모르겠네요.
필드들을 볼 수 있는 곳은 Jira 소프트웨어 서포트 페이지 링크로 Advanced searching - fields reference 여기서 볼 수 있습니다.
약 38개쯤 되는데요, 하나하나 보기 보다는 위 링크에서 보시면 좋을 것 같습니다. 우리가 주로 보는 필드 몇개만 소개를 해볼게요.

• Affected version: 반영된 버전의 의미로 사용할 수 있는 필드입니다. 프로젝트의 Releases에 있는 버전들을 입력할 수 있습니다.
• Assignee: 이슈의 담당자를 입력할 수 있는 필드입니다.
• Component: 프로젝트에 있는 컴포넌트를 입력할 수 있는 필드입니다.
• Summary: 이슈의 제목 필드입니다. Jira의 텍스트 검색 신텍스를 사용하여 검색할 수 있습니다.
• Description: 이슈의 설명 필드입니다.

이 외에도 많은 필드들이 있는데 각 필드마다 사용할 수 있는 기능(operation) 다릅니다.
예를 들면, Assignee 같은 경우 WAS WAS NOT CHANGED 등을 JQL에서 사용할 수 있습니다.
내가 담당했던 이슈를 찾을때는 WAS를 이용해서 찾아볼 수 있겠죠.
CHANGED는 변경이 언제 이뤄졌는지, 누가 변경했는지에 대해 쿼리해볼 수 있습니다.

자세한 내용은 Advanced searching - fields reference 이 페이지에서 참고하시면 좋을 것 같습니다. :)

커스텀 필드 (Custom Field)

커스텀 필드는 말그대로 사용자가 커스텀하게 만들 수 있는 필드를 뜻합니다.
만들 수 있는 필드의 타입은 여러가지가 있겠죠? 텍스트 형식부터 시작해서 사용자를 입력할 수 있거나, 텍스트 박스 등 여러 타입이 있습니다.

기본 타입(Standard type)

• Checkboxes: 체크박스 필드
• Date Picker: 날짜 설정 필드
• Date Time Picker: 날짜 + 시간 필드
• Labels: 레이블 필드 (입력시 자동완성 기능이 있음)
• Number Field: 숫자 입력 필드
• Radio Buttons: 라디오 버튼 필드 (하나만 선택 가능한 필드)
• Select List (cascading): 2개로 나눠진 드롭다운 선택 리스트 필드
• Select List (multiple choices): 여러개를 선택할 수 있는 드롭다운 선택 리스트 필드
• Select List (single choices): 한개만 선택할 수 있는 드롭다운 선택 리스트 필드
• Text Field (multi-line): 여러줄 입력할 수 있는 텍스트 필드
• Text Field (single line): 한줄 입력할 수 있는 텍스트 필드
• URL Field: URL을 입력할 수 있는 필드 (URL 클릭 가능)
• User Picker (single user): 사용자를 입력할 수 있는 필드

기본 타입 외에도 그룹을 입력할 수 있는 picker, 버전을 입력할 수 있는 picker, 읽을 수만 있는 read only text 필드도 있습니다.
필요한 커스텀 필드를 생성하여 필드 설정(Field Configuration)에 반영한다면 사용할 수 있겠죠?

주의(Warning)!
커스텀 필드는 기본적으로 생성될 때 모든 프로젝트의 필드 설정에 추가됩니다.
다른 프로젝트에서는 사용하지 않고 현재 관리하고 있는 프로젝트에서만 사용하고자할 경우 추가 설정해주셔야 합니다.
커스텀 필드 설정 -> Edit Configuration -> Choose applicable context -> Apply to issue under selected projects 옵션으로
생성한 커스텀 필드가 필요한 프로젝트에 반영될 수 있습니다. (다른 프로젝트에 의도하지 않게 필드가 추가되면 프로젝트에 영향을 주기 때문입니다.)

스크린 (Screen)

Jira에서 스크린은 이슈를 생성, 수정, 조회하는 모든 화면들을 이야기합니다.
Jira 서포트 문서(Defining a screen)에서는 아래와 같이 표현하고 있습니다.

Screens group all available fields (or a subset of all available fields) defined in Jira applications, and organize them for presentation to a user.

스크린은 Jira에 정의된 사용 가능한 모든 필드(또는 사용 가능한 모든 필드의 하위 집합)를 그룹화하고 사용자에게 보여주기 위해 이를 구성한다.

위 내용 정도로 정리해볼 수 있겠네요.
스크린은 앞서 말씀드렸던 이슈 생성/수정/조회에서 사용할 수 있을 뿐만 아니라 워크플로우에서 상태 변경시에도 사용할 수 있도록 설정할 수 있습니다.
추가로 스크린에 탭으로 입력하고자하는 정보들을 정리해서 입력할 수 있도록 설정할 수 있죠.

이슈와 스크린

앞서 스크린을 설명할 때에 이슈 생성/수정/조회에서 사용할 수 있다고 말씀드렸었습니다.
스크린 스킴에서 각 동작에 따라 스크린을 설정하는 화면을 보시면 이해가 빠를 것 같습니다.

위 화면 처럼 이슈 마다, 각 Create issue / Edit issue / View issue에 따라 스크린을 따로 만들어서 적용한 것을 볼 수 있습니다.
각 스크린은 다르게 설정할 수도 있고 다를 필요가 없다면 따로 설정할 필요 없이 같은 스크린을 사용해도 됩니다.

필드의 순서 설정도 가능하고, 탭을 추가해서 탭마다 입력하고자 하는 필드를 나눠서 둘 수도 있습니다.

워크플로우와 스크린

워크플로우에서도 스크린을 사용할 수 있다고 말씀드렸었습니다. 참고 jira 서포트 페이지:Map a screen to a workflow transition in Jira server
아래 그림처럼 상태 변경시에 스크린이 나올 수 있도록 설정할 수 있습니다.

자세한 내용은 위 서포트 페이지에 가보시면 Solution에 더 자세하게 나와있으니 참고해보세요!

마무리

Jira에서 빼놓을 수 없는 필드와 스크린을 알아보았습니다.
지금 작성해놓고 보니까 스크린의 내용이 약간 부족해보인다는 느낌이 있지만 어느 부분을 추가해야할지 모르겠네요. 향후 추가할 내용이 생긴다면 따로 포스트 추가해보겠습니다.
추후에 현재 프로젝트에서는 어떤 필드를 사용하고 있고 어떻게 스크린을 구성해서 사용하고 있는지 보여드리겠습니다.
긴 글 읽어주셔서 감사합니다. :)

Jira Scheme 시리즈

• Jira Schemes은 무엇일까? (1)
• Jira Schemes은 무엇일까? (2)

앞선 1편의 내용 뒤로 남은 스킴들에 대해 알아보는 포스트입니다.
1편에서는 Jira 프로젝트에서 주로 이슈와 관련하여 설정하곤하는 스킴에 대해 이야기해보았습니다.

2편에서는 프로젝트에서는 많이 변경하지 않지만 알아두면 프로젝트 관리에 도움이 될만한 스킴을 이야기해보겠습니다.

남은 스킴은 뭐가 남았나요?

• Issue Security Scheme(이슈 보안 스킴)
• Project Permission Scheme(프로젝트 권한 스킴)
• Notification Scheme(노티피케이션/알림 스킴)

남은 스킴은 이렇게 3개 정도가 되겠습니다.
(더 봐야하는 스킴이 남아있을 수 있지만 제가 알고 있는 스킴을 중심으로 정리해보았습니다.)
프로젝트 이슈에 대한 내용보다는 프로젝트 외적인 부분에 대한 내용으로 생각하고 보시면 될 것 같습니다.

Issue Security Scheme(이슈 보안 스킴)

이슈 보안 스킴은 이슈들에 대해 특정 인원에게 보여주거나 할당할 수 있도록 제한할 수 있는 스킴입니다.
스킴에 있는 보안 레벨(Security level)을 통해 사용자를 제한할 수 있습니다.

프로젝트에 설정되어있는 보안 레벨 스킴은 아래 경로에서 확인할 수 있습니다.
프로젝트 설정 -> Issue Security
대부분은 스킴이 설정되어있지 않을 겁니다. 프로젝트 안에서 특정 티켓들을 안보이게 하거나 할당되지 않게할 수 있는 설정이어서
외부인과 협업 또는 보안상 특별한 이슈가 없다면 사용할 일이 많지 않은 스킴이긴 합니다.

참고 문서: JIRA Security Level 설정하기 (Reporter와 Assignee만 해당 이슈 보기)
위 참고 문서에 잘 설명되어있네요. :)

Project Permission Scheme(프로젝트 권한 스킴)

프로젝트에서 프로젝트 역할(project role)이나 사용자에 따라 권한을 설정할 수 있는 스킴입니다.

위 페이지 화면 처럼, 퍼미션이 있고 각 권한을 프로젝트 역할, 그룹, 특정 사용자 등으로 설정할 수 있습니다.
설정에 따라 권한을 가지고 있는 사용자만 프로젝트를 접근하거나 댓글을 달 수 있도록 할 수 있습니다.
설정 가능한 옵션을 좀 더 본다면 아래와 같습니다.

위 화면에서도 보실 수 있겠지만 한번 정리해봅니다.

• 프로젝트 역할 (Project Role): 현재 Jira에 있는 프로젝트 역할 리스트를 추가할 수 있습니다.
• 응용프로그램 엑세스(Application access): 로그인한 사용자 또는 Jira 소프트웨어 사용자 그룹으로 추가할 수 있습니다.
• 그룹(Group): Jira에 있는 그룹으로 추가할 수 있습니다.
• 보고자(Reporter): 이슈를 생성한 사용자를 추가합니다.
• 단일 사용자(Single user): 특정 사용자를 추가합니다.
• 프로젝트 책임자(Project lead): 프로젝트 책임자를 추가합니다.
• 현재 담당자(Current assignee): 이슈의 담당자를 추가합니다.
• 사용자 정의 필드 값(User custom field value): 사용자 타입의 커스텀 필드에 있는 사용자를 추가합니다.
• 그룹 사용자 정의 필드 값(Group custom field value): 그룹 사용자 타입의 커스텀 필드에 있는 사용자를 추가합니다.

권한을 추가할 수 있는 사용자 옵션도 많고, 권한 종류도 많습니다.
수정할 수 있는 권한 카테고리는 아래와 같이 정리해볼 수 있을 것 같네요.

• 프로젝트 권한
• 이슈 권한
• 투표자(Vote), 지켜보기(Watch) 권한
• 댓글(Comment) 권한
• 첨부파일(Attachments) 권한
• 시간 추적(Worklog) 권한

Notification Scheme(노티피케이션/알림 스킴)

알림 스킴은 이슈에서 발생하는 이벤트에 대한 알림 중 어떤 것을 누구에게 보낼 것인지를 설정할 수 있는 스킴입니다.
이슈가 생성되고 변경되었을 때 알림 메일을 받을 것인지 등을 설정할 수 있습니다.

각 이벤트에 따라 알림을 받을 사용자, 사용자 그룹을 설정할 수 있습니다.
프로젝트 권한 스킴 설정과 비슷하게 알림을 받을 사용자들을 추가할 수 있습니다.
각 알림 항목에 알림을 받을 사용자를 추가할 수 있는 옵션은 다음과 같습니다.

• Current Assignee
• Reporter
• Current User
• Project Lead
• Component Lead
• Single User
• Group
• Project Role
• All Watchers
• User Custom Field Value
• Group Custom Field Value

알림 이벤트는 이슈 생성, 이슈 수정, 이슈 할당, 이슈 해결 부터 댓글 추가, 댓글 업데이트 등이 있어서
필요한 이벤트에 대해 알림이 필요한 사용자들을 추가할 수 있습니다.

마무리

스킴 관련한 내용은 2개의 포스트로 마무리할 수 있었네요.
저도 이번에 정리하면서 Jira에 있는 스킴들을 공부할 수 있었어서 좋았고 나중에 활용할 수 있는 방법을 고민할 수 있게된 계기가 되어 좋았습니다.

긴 글 읽어주셔서 감사합니다. :)

Jira Scheme 시리즈

• Jira Schemes은 무엇일까? (1)
• Jira Schemes은 무엇일까? (2)

Jira에서 프로젝트를 생성한 뒤에 이슈, 워크플로우, 권한 등을 설정하는데
많이 들어보셨으리라 예상하는 스킴(Scheme)에 대해 이야기해보자 합니다.

설정할 때, 기존에 사용하던 스킴을 사용할 수도 있고 내 입맛대로 변경한 스킴을 사용할 수도 있어요.
이번 포스트에서는 스킴이란 무엇인지, 어떤 스킴들이 있는지만 짚어보겠습니다.

참고

• 이 포스트는 Jira 언어 설정을 영어로 해두어서 한국어로 설정하신 분들의 화면과는 다를 수 있습니다)
• 스킴에 대한 설정은 프로젝트 어드민이 아닌 시스템 어드민 권한이 있어야 가능합니다.

Jira Scheme(스킴)

Jira에는 여러 스킴이 있는데 대부분 프로젝트를 기준으로 설정 가능합니다.
스킴 하나를 여러가지 프로젝트에 적용할 수도 있고 프로젝트마다 따로 스킴을 만들어 적용할 수도 있습니다.
(스킴 하나를 공유하는 프로젝트의 경우 스킴 변경을 신중하게 해야합니다. 다른 프로젝트에 영향을 주기 때문이죠)

이슈 타입, 워크플로우, 필드, 우선순위(Priority), 권한(Permission) 등을 설정할 수 있습니다.
먼저 Jira에서 설명하는 내용을 보고난 뒤에 하나하나 살펴보겠습니다. (좋은 그래프가 있어서 첨부해봅니다.)

Jira Docs 설명

Project screens, schemes and fields (EN)

원문

Information for each issue is held in the fields that are associated with that issue. You can tailor these fields to suit your organization’s needs. The diagram below is a representation of how these fields are associated with an issue, via screens and schemes. A screen is the user’s view of an issue, and the screen is mapped to a specific issue operation (such as creating an issue, or editing an issue) via a screen scheme. The screen scheme is then mapped to an issue type via the issue type screen scheme. This configuration is associated with the project, and is applicable to all issues within the project.

번역문
각 이슈에 대한 정보는 해당 이슈와 관련된 필드에 있습니다. 조직의 요구에 맞게 이 필드를 조정할 수 있습니다. 아래 다이어그램은 스크린(화면) 및 스킴(구성표)을 통해 이러한 필드가 이슈와 연결되는 방식을 나타냅니다. 스크린은 사용자가 이슈를 볼 수 있는 화면이며 스크린 스킴을 통해 특정 이슈 작업 (예 : 이슈 생성 또는 이슈 편집)에 맵핑됩니다. 그런 다음 스크린 스킴은 이슈 타입 스크린 스킴을 통해 이슈 타입에 맵핑됩니다. 이 구성은 프로젝트와 관련이 있으며 프로젝트 내의 모든 이슈에 적용됩니다.

설명을 대략 구글 번역기로 돌렸는데 깔끔하게 번역된 것 같습니다. (의미로 번역하지 않고 되도록 음차로 두고 정리해두었습니다.)
위 그림 및 설명대로 스킴, 설정들이 묶여 동작하고 있는 것을 아래에서 설명드리겠습니다. 가보시죠!

Issue types Scheme(이슈 타입 스킴)

이슈 타입 스킴은 이슈 타입에 대한 것을 정의합니다.
이 스킴은 프로젝트 -> Project settings(프로젝트 설정) -> issue types(이슈 타입)에서 볼 수 있습니다.

위 화면에서 볼 수 있듯이,
현재 프로젝트에서 사용하고 있는 이슈 타입들을 설정할 수 있습니다.
설정은 위에 Actions 버튼을 누르면 Edit issue types가 나옵니다.

해당 프로젝트에서 사용할 이슈 타입을 스킴 수정을 통해 추가/삭제할 수 있습니다.
변경하고자하는 이슈 타입을 드래그&드롭으로 옮겨서 설정합니다.
프로젝트에서 기본적으로 생성되는 이슈 타입도 설정할 수 있습니다. (Default issue type)

관련 컨플루언스 링크

• Adding, editing, and deleting an issue type scheme(EN)
• Issue type schemes(EN)

Workflow Scheme(워크플로우 스킴)

이슈 타입 스킴과 같이 프로젝트 설정 -> Workflows(워크플로우) 메뉴에서 볼 수 있습니다.
눌러보면 프로젝트에서 사용하는 각 이슈 타입에 할당되어있는 워크플로우를 볼 수 있습니다.
(현재 세팅되어있는 이슈 타입, 워크플로우 스킴 세팅에 따라 화면은 다르게 보일 수 있습니다.)

위 화면에서 스킴을 수정할 수는 없고 스킴을 변경하는 Switch Scheme 버튼으로 다른 스킴으로 변경할 수 있습니다.
현재 있는 스킴들 중 하나를 골라서 변경할 수 있습니다. 다만 미리 만들어두고 설정해야겠죠.

화면에서 볼 수 있듯 현재 워크플로우 스킴은 지금 프로젝트 외에 다른 2개의 프로젝트에도 적용되어있습니다.
This workflow scheme is being used by multiple projects 라는 문구가 있는데,
다른 프로젝트도 사용하고 있는 스킴을 변경하려면 워크플로우 스킴 페이지로 가서 변경해야한다는 이야기입니다.

Workflow Schemes를 누르면, 워크플로우 스킴을 변경할 수 있는 페이지가 나옵니다.
페이지로 가보면 이슈 타입에 워크플로우를 추가하거나 수정, 삭제할 수 있습니다.
설정되어있는 워크플로우 내용을 Text, Diagram 타입으로 볼 수 있습니다.

첫 항목의 All Unassigned issue Types는 아래에 할당되어있는 이슈 타입 외에
모든 이슈 타입에 대해 PUBG Workflow가 적용된다는 것 입니다.
지금 사용하는 프로젝트는 Epic, Task, Sub-Task 이슈 타입이 PUBG Workflow(기본 워크플로우)를 사용하고 있습니다.

Screen Scheme(스크린 스킴)

프로젝트 설정 -> Screens 메뉴에서 볼 수 있습니다.
어떤 스크린 스킴들이 설정되어있는지 볼 수 있고, 설정은 어드민 페이지에 가서 수정할 수 있습니다.

여기서는 각 이슈가 Create/Edit/View(생성/수정/조회) 시 볼 수 있는 스크린을 각각 설정할 수 있습니다.
처음 스크린 스킴 생성시에는 Default로 한가지 스크린이 생성되어있으며 각각의 경우에 맞게 스크린을 생성하여 설정할 수 있습니다.
(위 화면에서 볼 수 있듯 Task, Epic, Sub-task의 각각의 경우에 맞게 스크린을 설정해두었습니다.)

각 이슈에 맞게 스크린 스킴이 설정되어있는 것을 보실 수 있을 겁니다.
상위에 이슈 타입 스크린 스킴(Issue type screen schemes)에 따라 설정되어있는 것인데 다음 순서에 설명하겠습니다.

여기서 스크린이란?

• 이슈의 생성/수정/조회 시 보여지는 필드를 정의한 것을 의미합니다.
• 이슈 생성시 필요한 스크린의 경우 Summary, Description, Assignee, priority 등이 필요할 수 있겠죠?
• 이슈 화면에서 입력이 필요하거나 보여줘야하는 내용이 있다면 설정할 수 있습니다.
• 위에 Field Tab의 기능을 이용하면 탭을 이용하여 입력해야하는 필드를 나눠서 보여줄 수도 있습니다.

Issue type screen schemes(이슈 타입 스크린 스킴)

이슈 타입 스크린 스킴은 각 이슈 타입에 따라 스크린 스킴을 설정할 수 있는 스킴입니다.
어떻게 보면 스크린 스킴과 이슈 타입 스킴을 연결해주는 스킴이라고 볼 수 있겠네요.
위 스크린 스킴 메뉴 화면에서 오른쪽 상단의 Actions -> Edit screens를 통해 수정할 수 있습니다.

설정 페이지 오른쪽 상단의 Associate an issue type with a screen scheme 메뉴 버튼을 통해 이슈 타입과 스크린 스킴을 연결할 수 있습니다.
기존에 있던 항목의 Edit버튼을 누를 경우, 다른 스크린 스킴으로 변경하는 설정화면이 나옵니다.

Field Scheme(필드 스킴)

필드 스킴은 프로젝트에서 사용하는 이슈 타입 들의 필드 항목을 정의하는 스킴입니다.
필드 스킴에서는 각 이슈 타입에 사용할 필드를 정의한 Field configuration(필드 설정)을 설정합니다.
프로젝트 설정 화면에서 오른쪽 상단의 Actions -> Edit screens를 통해 수정할 수 있습니다.

설정 페이지 오른쪽 상단의 Associate an issue type with a field scheme 메뉴 버튼을 통해 이슈 타입과 필드 설정을 연결할 수 있습니다.
현재는 Bug 이슈 타입 외에 몇가지 커스텀한 설정이 되어있지만 Epic, Task, Sub-task 타입은 Default 필드 설정을 사용하고 있습니다.
각 항목의 Edit 버튼을 누를 경우, 다른 필드 설정으로 변경하는 설정화면이 나옵니다.

필드 설정(Field configuration)이란?

• 이슈에 입력할 수 있는 필드를 설정합니다.
• 입력 필드의 옵션도 설정할 수 있습니다.
  • 필수 입력(Required), 보여지지 않게 할지 등
• 필요하지 않은 필드는 숨김(Hide) 처리할 수 있습니다.

Priority Scheme(우선순위 스킴)

프로젝트 설정에 이슈와 직접적인 관계가 있는 스킴 중 마지막 스킴이라고 할 수 있겠습니다.
이슈의 우선순위 값을 어떤 값을 입력할 수 있게할지 설정하는 스킴입니다.
주로 Blocker, Critical, Major, Minor, Trivial(Nonessential) 정도로 설정하는 것으로 알고 있습니다.

다른 스킴들과 다른 것은 우선순위 값이 시스템에 묶여 있어 순서를 변경하기 힘들다는 것입니다.
그래서 이슈 검색 시, 우선순위 정렬이 종종 안맞는 경우가 있어 확인해보면 우선순위 정렬이 안맞는 경우가 있습니다.
스킴에 묶여 있는 순서가 아닌 시스템 우선순위 값 정렬에 따라 정렬되니 참고하세요!

나중에 우선순위 정렬에 대한 것이 스킴에 맞게 정렬될 수 있으면 좋겠네요.
다만 생각해보면, 다른 우선순위 스킴을 가지고 있는 여러 프로젝트의 이슈들의 우선순위를 정렬하려면 그렇게 하기 힘들 수 있겠다는 생각도 드네요.

마무리

스킴에 대한 것이 아직 몇개 남았지만 프로젝트의 이슈와 연관이 큰 스킴을 중심으로 다루어 보았습니다.
남은 스킴들은 이슈 보안, 노티피케이션, 퍼미션 정도가 남았는데 다음 포스트를 통해 소개하겠습니다.
긴 글 읽어주셔서 감사합니다.

스크립트러너에서 Jira 이슈의 Label 추가에 따라 자동으로 특정 사람들을 와쳐(watcher)에 추가하는 방법을 다뤄봅니다.

시스템 테스트 환경

• Jira: Jira Software 8.3.2
• ScriptRunner: 5.6.1.1-jira8

참고 포스트

• Listener에 대한 내용 참고 포스트: ScriptRunner 소개 2
• Label 관련 내용을 다룬 포스트: ScriptRunner Label 다루기

사용 시나리오

적용하는 방법 전에 제가 사용하고 있는 시나리오를 공유드립니다.
특정 이벤트에 따라 와쳐를 추가할 수 있으니 이벤트만 잘 고려해서 와쳐 추가 코드만 사용하셔도 괜찮습니다.

1. 특정 레이블(Label)이 이슈에 추가됨
2. 레이블이 추가된 이슈에 원하는 인원을 와쳐 필드에 입력함
3. 와쳐 인원 입력은 복수의 인원이 가능해야함

여기서 특정 이벤트는 레이블 추가 입니다.
다른 이벤트의 예시로는 컴포넌트 추가, 특정 커스텀 필드 값의 변경 등 다양하게 조건을 변경해볼 수 있을 것 같네요.

적용

앞서 설명드린 시나리오대로 적용해보겠습니다.
바로 적용해보고 싶으신 분들을 위해 먼저 코드와 설정 화면을 보여드리겠습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

import com.atlassian.jira.component.ComponentAccessor;
import java.util.List;

def watcherManager = ComponentAccessor.getWatcherManager();
def userManager = ComponentAccessor.getUserManager();
// Add users to watcher field
def watchUsers = {usernames ->
  usernames.each {
    def user = userManager.getUserByKey(it.toString());
    watcherManager.startWatching(user, event.issue);
  }
}
// Remove users on watcher field
def unwatchUsers = {usernames ->
  usernames.each {
    def user = userManager.getUserByKey(it.toString());
    watcherManager.stopWatching(user, event.issue);
  }
}
def labelWatch = {String label, List users, String[] oldArr, String[] newArr, boolean isCaseSensitive ->
  String[] tmpOldArr = oldArr.collect {String i ->
    if (isCaseSensitive)
      return i;
    else
      return i.toLowerCase();
  };
  String[] tmpNewArr = newArr.collect {String i ->
    if (isCaseSensitive)
      return i;
    else
      return i.toLowerCase();
  }
  String tmpLabel = isCaseSensitive ? label : label.toLowerCase();
  if (tmpOldArr.contains(tmpLabel) == false && tmpNewArr.contains(tmpLabel) == true) {
    watchUsers(users);
  }
  if (tmpOldArr.contains(tmpLabel) == true && tmpNewArr.contains(tmpLabel) == false) {
    unwatchUsers(users);
  }
}
def labelWatchCreated = {String label, List users, boolean isCaseSensitive ->
  String[] labels = event.issue.labels as String[];
  String[] tmpLabels = labels.collect {String i ->
    if (isCaseSensitive)
      return i;
    else
      return i.toLowerCase();
  }
  String tmpLabel = isCaseSensitive ? label : label.toLowerCase();
  if (tmpLabels.contains(tmpLabel)) {
    watchUsers(users);
  }
}

def change = event?.getChangeLog()?.getRelated("ChildChangeItem")?.find {it.field == "labels"};

if (change) {
  // Issue Updated case
  String[] oldArr = change.oldstring.toString().tokenize();
  String[] newArr = change.newstring.toString().tokenize();

  labelWatch("m", ["m1", "m2", "m3"], oldArr, newArr, false);
  labelWatch("b", ["b1", "b2", "b3", "b4", "b5"], oldArr, newArr, true);
} else {
  // Issue Created case: ${event.issue} ${event.issue.labels}
  labelWatchCreated("m", ["m1", "m2", "m3"], false);
  labelWatchCreated("b", ["b1", "b2", "b3", "b4", "b5"], true);
}

참고

위와 같이 설정하고 Update 버튼을 눌러주시면 적용됩니다.
코드가 깔끔하지는 않으나 동작하고 있는 코드입니다. (코드 개선은 향후 조금씩 진행해보겠습니다.)
다만 적용 전에 각자에 맞게 설정해야하는 값은 아래와 같습니다.

1. labelWatch()를 호출시 “m”은 레이블 이름을, []안에는 와쳐 필드에 추가하고자 하는 유저의 아이디들을 입력해주세요.
2. labelWatchCreated()를 호출시 1번 항목과 동일하게 입력해주세요.

• 이 함수를 추가하는 이유는 이슈 생성시 이벤트가 다르게 처리되기 때문입니다.
• 이슈 생성시 이벤트를 실행시키지 않고자 한다면 해당 코드를 지워도 괜찮습니다.

3. labelWatch(), labelWatchCreated() 함수 마지막 인자는 레이블의 대소문자를 구분할 것인지에 대한 변수입니다.

• 레이블 값의 대소문자를 구분하고자한다면 true, 아니라면 false 값을 넣고 호출해주세요.

코드 설명

코드에 대한 설명 내용이 많지않지만 각 함수별로 짧게 설명드리겠습니다.

watchUsers(usernames) / unwatchUsers(usernames)

변수로 전달받은 유저들을 이벤트가 발생한 이슈의 와쳐 필드에 입력/삭제합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

def watcherManager = ComponentAccessor.getWatcherManager();
def userManager = ComponentAccessor.getUserManager();
// Add users to watcher field
def watchUsers = {usernames ->
  usernames.each {
    def user = userManager.getUserByKey(it.toString());
    watcherManager.startWatching(user, event.issue);
  }
}
// Remove users on watcher field
def unwatchUsers = {usernames ->
  usernames.each {
    def user = userManager.getUserByKey(it.toString());
    watcherManager.stopWatching(user, event.issue);
  }
}

• 유저를 의미하는 usernames이라는 string 배열 인수를 받아 처리합니다.
• watcherManager에 있는 startWatching(), stopWatching() 함수로 와쳐를 추가하고 삭제합니다.

labelWatch (label, users, oldArr, newArr, isCaseSensitive)

레이블과 변경전 레이블 배열, 변경후 레이블 배열을 받아 레이블이 변경되었는지 확인합니다. 추가적으로 isCaseSensitive 인수를 통해 레이블의 대소문자를 구분하여 확인합니다.
확인 후, 받은 유저들을 이슈의 와쳐 필드에 추가 또는 삭제합니다.
(watchUsers(), unwatchUsers() 함수로)
이슈가 업데이트될 경우에만 호출되는 함수입니다. 생성시에는 아래에 있는 labelWatchCreated() 함수가 호출됩니다.

labelWatchCreated(label, users, isCaseSensitive)

이슈 생성시에는 변경된 사항이 없기에 issue Created 이벤트를 받아 처리해야했습니다.
추가 함수를 통해 이슈 생성시에도 와쳐가 추가될 수 있도록 만든 함수입니다.

labelWatch() 함수처럼 레이블과 유저를 받고 받은 레이블이 값에 있을 경우 유저를 이슈의 와쳐 필드에 추가합니다.

실행 코드

실행 코드는 위에서 설명한 함수를 사용하여 와쳐 추가를 실행합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

def change = event?.getChangeLog()?.getRelated("ChildChangeItem")?.find {it.field == "labels"};

if (change) {
  // Issue Updated case
  String[] oldArr = change.oldstring.toString().tokenize();
  String[] newArr = change.newstring.toString().tokenize();

  labelWatch("m", ["m1", "m2", "m3"], oldArr, newArr, false);
  labelWatch("b", ["b1", "b2", "b3", "b4", "b5"], oldArr, newArr, true);
} else {
  // Issue Created case: ${event.issue} ${event.issue.labels}
  labelWatchCreated("m", ["m1", "m2", "m3"], false);
  labelWatchCreated("b", ["b1", "b2", "b3", "b4", "b5"], true);
}

마무리

실제로 빠르게 적용해보고 사용해본 코드라 깔끔하지 않을 수 있지만
다른분들도 사용해볼 수 있도록 포스트해보았습니다.

업무에 도움이 될 수 있기를 바라며 다른 방법도 추후에 올려보겠습니다.
감사합니다.

스크립트러너에서 Jira 이슈의 Label 값을 수정하는 경우가 종종 있는데 어떻게 추가/수정하는지
이번 포스트에서 다뤄보겠습니다.

이번에도 Script Console에서 코드를 실행시켜보고 저는 어떤 케이스에서 사용하는지 설명드리겠습니다.

시스템 테스트 환경

스크립트러너는 Jira 버전에 영향을 좀 받아서 환경도 미리 알고 계셔야합니다.
(버전에 따라 내부 함수들이 변경됨에 따라 실제 코드도 조금씩 변경됩니다)

• Jira: Jira Software 8.3.2
• ScriptRunner: 5.6.1.1-jira8

Label 값 가져오기

Label 값을 가져오는 것은 쉽습니다.
이슈에서 기본적으로 사용하는 필드라서 다루기 쉬운 것이 장점입니다.

1
2
3
4
5
6
7
8
9

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.label.LabelManager;
import com.atlassian.jira.issue.MutableIssue;

LabelManager labelManager = ComponentAccessor.getComponent(LabelManager);
def issueMgr = ComponentAccessor.getIssueManager();
MutableIssue issue = issueMgr.getIssueObject("PUBGTEST-169");

labelManager.getLabels(issue.getId());

getLabels(Long issueId)

getLabels() 함수는 issueId 값을 받아 이슈의 label 값을 가져옵니다.
함수의 리턴 값은 label들을 포함한 배열로 리턴합니다.
(아래 결과 값은 이슈에 테스트로 Label 값을 입력한 것을 기반으로 스크립트 결과가 나온 것입니다.)

Result

[Promotion, art]

Label 값 추가하기

Label 값을 가져오는 것보다는 한가지 더 고려가 필요한 추가 입니다.
Label 값을 추가할 때에는 어떤 사용자가 값을 추가할 것인지 결정이 필요합니다.
먼저 코드를 보면서 설명을 드리겠습니다.

1
2
3
4
5
6
7
8
9
10
11

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.label.LabelManager;
import com.atlassian.jira.issue.MutableIssue;
  
def user = ComponentAccessor.getUserManager().getUserByKey("pubg-helper");
LabelManager labelManager = ComponentAccessor.getComponent(LabelManager);
def issueMgr = ComponentAccessor.getIssueManager();
MutableIssue issue = issueMgr.getIssueObject("PUBGTEST-169");

labelManager.addLabel(user, issue.getId(), 'test', false);
labelManager.getLabels(issue.getId());

코드 설명

앞서 Label 값을 가져오는 것과 비교해서 달라진 것은 아래 코드와 addLabel() 함수 입니다.
def user = ComponentAccessor.getUserManager().getUserByKey("pubg-helper");
위 코드는 Label을 추가할 사용자를 결정하기 위해 사용자 객체를 아이디로 가져온 것입니다.

ScriptRunner의 Listener 기능에서 Label 수정/추가 기능을 사용할 때,
위 코드를 통해 업데이트하는 사용자를 동적으로 변경할 수 있습니다.

addLabel(User remoteUser, Long issueId, String label, boolean sendNotification) 함수는 이슈에 Label을 하나 추가할 수 있는 함수입니다.
함수 레퍼런스: docs.atlassian.com/…/LabelManager/addLabel

Result

[Promotion, art, test]

Label 값 변경

앞서 Label 추가의 경우 하나씩 추가했던 것에 비해 Label 값을 변경하는 것은 LabelManager의 setLabels() 함수를 사용합니다.

1
2
3
4
5
6
7
8
9
10
11

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.label.LabelManager;
import com.atlassian.jira.issue.MutableIssue;
  
def user = ComponentAccessor.getUserManager().getUserByKey("pubg-helper");
LabelManager labelManager = ComponentAccessor.getComponent(LabelManager);
def issueMgr = ComponentAccessor.getIssueManager();
MutableIssue issue = issueMgr.getIssueObject("PUBGTEST-169");

labelManager.setLabels(user, issue.getId(), ['test'] as Set, false, true);
labelManager.getLabels(issue.getId());

labelManager.setLabels()

labelManager.setLabels() 함수는 Label 값을 추가, 삭제한다기보다는
새로운 값으로 재설정한다는 것으로 이해하시면 될 것 같습니다.

public Set<Label> setLabels (User remoteUser, Long issueId, Set<String> labels, boolean sendNotification, boolean causeChangeNotification)

여기서 중간에 labels 값에 Set으로 되어있는데 그냥 [] 배열로 넣을 경우 List 객체로 인식하는 문제가 생깁니다.
그래서 as Set으로 변경해준 것으로 이해해주시면 됩니다. (혹은 변수를 따로 Set으로 두고 입력하면 됩니다)

labelManager.setLabels() 함수 레퍼런스: docs.atlassian.com/…/LabelManager/setLabels

Result

[test]

마무리

Label 값을 가져오고 추가/설정하는 것은 어렵지 않은 것 같습니다. (커스텀 필드 수정에 비해서요)
다만 골라서 삭제하는 기능은 없어 setLabels와 기존에 있는 값을 비교해서 삭제하는 것으로 삭제할 수는 있어 보이네요. (그렇게 어려워 보이지는 않을 것 같긴 하네요.)

저는 특정 이벤트가 발생할 경우 Label을 추가하는 정도로만 Listener에 Custom Listener를 추가하여 사용하고 있습니다. 이 Label을 사용하여 보드를 만들어 사용하시는 분이 있는데 잘 사용하고 있다고 하네요. :)

다음에 다른 기능을 소개하는 포스트로 찾아뵙겠습니다.
감사합니다!