서비스 데스크 사용하기

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed

서비스 데스크를 사용하여 문제를 생성하거나 응답할 수 있습니다.
이 문제에서는 친근한 이웃 Support Bot도 확인할 수 있습니다.

서비스 데스크 이메일 주소 보기

프로젝트의 서비스 데스크 이메일 주소를 확인하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 모니터링 > 서비스 데스크를 선택합니다.

이메일 주소는 문제 목록 상단에 표시됩니다.

최종 사용자(문제 작성자)로서

서비스 데스크 문제를 생성하려면 최종 사용자가 GitLab 인스턴스에 대해 아는 것이 필요하지 않습니다.
그들은 받은 주소로 이메일을 보내기만 하면 되며, 수신 확인 이메일을 다시 받게 됩니다:

서비스 데스크 활성화

이 또한 최종 사용자에게 구독 취소 옵션을 제공합니다.

구독을 취소하지 않으면 문제에 추가된 새로운 댓글은 이메일로 전송됩니다:

서비스 데스크 응답 이메일

그들이 이메일로 보낸 모든 응답은 문제 자체에 표시됩니다.

추가 정보는 외부 참가자 및 이메일 처리에 사용되는 헤더를 참조하세요.

GitLab UI에서 서비스 데스크 티켓 생성

  • 도입됨 GitLab 16.9에서 convert_to_ticket_quick_action이라는 플래그와 함께. 기본적으로 비활성화됨.
  • 일반 사용 가능 GitLab 16.10에서. 기능 플래그 convert_to_ticket_quick_action이 제거됨.

UI에서 서비스 데스크 티켓을 생성하려면:

  1. 문제 생성
  2. 빠른 작업 /convert_to_ticket user@example.com만 포함된 댓글을 추가합니다.
    GitLab Support Bot로부터 댓글을 볼 수 있어야 합니다.
  3. 페이지를 새로 고쳐서 UI가 유형 변경을 반영하도록 합니다.
  4. 선택 사항. 티켓에 댓글을 추가하여 외부 참가자에게 초기 서비스 데스크 이메일을 보냅니다.


과정을 보려면 UI 및 API를 통한 서비스 데스크 티켓 생성(GitLab 16.10)를 참조하세요.

문제에 대한 응답자

문제에 대한 응답자에게는 모든 것이 다른 GitLab 문제처럼 작동합니다.
GitLab은 응답자가 고객 지원 요청을 통해 생성된 문제를 보고 필터링하거나 상호작용할 수 있는 익숙한 느낌의 문제 추적기를 표시합니다.

서비스 데스크 문제 추적기

최종 사용자로부터의 메시지는 특별한 Support Bot 사용자로부터 오는 것으로 표시됩니다.
GitLab에서 일반적으로 하듯이 댓글을 읽고 작성할 수 있습니다:

서비스 데스크 문제 스레드

  • 프로젝트의 가시성(비공개, 내부, 공개)은 서비스 데스크에 영향을 미치지 않습니다.
  • 그룹 또는 네임스페이스를 포함한 프로젝트의 경로가 이메일에 표시됩니다.

서비스 데스크 문제 보기

준비 사항:

  • 프로젝트에 대해 최소한 Reporter 역할이 필요합니다.

서비스 데스크 문제를 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

  2. 모니터링 > 서비스 데스크를 선택합니다.

재설계된 문제 목록

서비스 데스크 문제 목록은 일반 문제 목록과 더 밀접하게 일치합니다.

사용 가능한 기능은 다음과 같습니다:

서비스 데스크 문제 목록에서 새 문제를 생성하는 옵션은 더 이상 없습니다.

이 결정은 새 문제가 전용 이메일 주소로 이메일을 통해 생성되는 서비스 데스크의 특성을 더 잘 반영합니다.

문제 목록 필터링

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

  2. 모니터링 > 서비스 데스크를 선택합니다.

  3. 문제 목록 위에서 검색 또는 필터 결과를 선택합니다.

  4. 표시되는 드롭다운 목록에서 필터링할 속성을 선택합니다.

  5. 속성을 필터링하는 데 사용할 연산자를 선택하거나 입력합니다. 다음 연산자를 사용할 수 있습니다:

    • =: 이다
    • !=: 이 중 하나가 아니다

  6. 속자를 필터링할 텍스트를 입력합니다.

    일부 속성은 없음 또는 모두로 필터링할 수 있습니다.

  7. 여러 속성으로 필터링하려면 이 프로세스를 반복합니다. 여러 속성은 논리적 AND로 결합됩니다.

OR 연산자로 필터링

OR 연산자로 필터링하기가 활성화되면,

문제 목록을 필터링할 때 is one of: ||를 사용할 수 있습니다:

  • 수신자
  • 레이블

is one of는 포함하는 OR를 나타냅니다. 예를 들어, Assignee is one of Sidney Jones와 Assignee is one of Zhang Wei로 필터링하면 GitLab은 Sidney, Zhang 또는 두 사람 모두가 수신자인 문제를 표시합니다.

ID로 문제 필터링

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

  2. 모니터링 > 서비스 데스크를 선택합니다.

  3. 검색 상자에 문제 ID를 입력합니다. 예를 들어, 필터 #10을 입력하여 오직 문제 10만 반환합니다.

이메일 내용 및 형식

HTML 이메일의 특별 HTML 형식

  • GitLab 15.9 에 도입됨 플래그인 service_desk_html_to_text_email_handler와 함께. 기본적으로 비활성화되어 있습니다.
  • GitLab 15.11에서 일반적으로 사용 가능. 기능 플래그 service_desk_html_to_text_email_handler가 제거되었습니다.

HTML 이메일은 다음과 같은 HTML 형식을 보여줍니다:

  • 테이블
  • 블록 인용
  • 이미지
  • 축소 가능한 섹션

댓글에 첨부된 파일

댓글에 첨부 파일이 포함되어 있고 총 크기가 10MB 이하인 경우, 이러한 첨부 파일은 이메일의 일부로 전송됩니다. 다른 경우에는 이메일에 첨부 파일에 대한 링크가 포함됩니다.

GitLab 15.9 이전에는 댓글에 대한 업로드가 이메일의 링크로 전송됩니다.

일반 문제를 서비스 데스크 티켓으로 변환

빠른 작업 /convert_to_ticket external-issue-author@example.com을 사용하여 일반 문제를 서비스 데스크 티켓으로 변환할 수 있습니다. 이렇게 하면 제공된 이메일 주소가 티켓의 외부 저자로 할당되고 외부 참가자 목록에 추가됩니다. 이들은 티켓에 대한 모든 공개 댓글에 대해 서비스 데스크 이메일을 수신하고, 이러한 이메일에 회신할 수 있습니다. 회신은 티켓에 새 댓글을 추가합니다.

GitLab은 기본 thank_you 이메일을 전송하지 않습니다. 티켓이 생성되었음을 최종 사용자에게 알리기 위해 티켓에 공개 댓글을 추가할 수 있습니다.

개인 정보 고려사항

서비스 데스크 문제는 기밀로, 프로젝트 구성원에만 보입니다. 프로젝트 소유자는 문제를 공개로 전환할 수 있습니다. 서비스 데스크 문제가 공개로 전환되면, 문제 작성자 및 참가자의 이메일 주소는 해당 프로젝트의 Reporter 역할 이상을 가진 로그인 사용자에게 표시됩니다.

GitLab 15.8 이전에는 서비스 데스크 문제가 공개로 전환되면, 문제 작성자의 이메일 주소가 프로젝트를 볼 수 있는 모든 사람에게 공개됩니다.

프로젝트의 모든 사용자는 자신의 역할에 관계없이 이 프로젝트에서 문제를 생성하기 위해 서비스 데스크 이메일 주소를 사용할 수 있습니다.

고유 내부 이메일 주소는 GitLab 인스턴스의 최소 Reporter 역할을 가진 프로젝트 구성원에게 보입니다. 외부 사용자(문제 작성자)는 정보 노트에 표시된 내부 이메일 주소를 볼 수 없습니다.

서비스 데스크 문제 이동

서비스 데스크 문제를 GitLab에서 일반 문제를 이동하는 것과 같은 방법으로 이동할 수 있습니다.

서비스 데스크 문제가 서비스 데스크가 활성화된 다른 프로젝트로 이동되면, 문제를 생성한 고객은 이메일 알림을 계속 수신합니다. 이동된 문제는 먼저 닫혔다가 복사되므로 고객은 두 문제 모두의 참가자로 간주됩니다. 그들은 이전 문제와 새 문제 모두에서 알림을 계속 수신합니다.