공개 지원 커뮤니티에서 '개인 지원'을 제공하다

기여 기능
1

이 주제에 대해 한동안 고민해 왔고, 이제 내 아이디어를 그룹에 공유하고 여러분의 생각을 듣고자 합니다.

지난 몇 달간 저는 기존(공개) 커뮤니티 지원 포럼을 보완하기 위해 직접적인 클라이언트 지원(즉, 지원 팀이 기밀이 필요한 클라이언트별 문제를 해결하는 방식)을 구축하려는 많은 분들과 이야기를 나눴습니다.
대부분의 솔루션은 ‘assign’, ‘solved’, ‘ticket’ 플러그인을 포함하며, 여러 가지 접근 방식이 있지만(골든 불릿은 없는 것 같고, 그래서 이 주제를 만들었습니다).

솔루션 #1: 각 클라이언트별로 별도의 카테고리/그룹 생성

이 방식은 클라이언트 수가 상대적으로 적을 때만 작동하며, 수백 개에 달할 때는 적용하기 어렵습니다.

솔루션 #2: schungx가 설명한 방식 “Discourse를 개인 지원/티켓 시스템으로 사용하는 방법”

여기서 가장 큰 걸림돌은 이 부분입니다: “(…) 당신이 전용 티켓팅 플랫폼을 구축하는 것이거나, 최소한 Discourse 웹 인터페이스 사용자와 지원 티켓을 요청하는 사용자 사이에 겹침이 없어야 한다는 점입니다.”

하지만 이 주제는 주요 문제 중 하나를 다루고 있습니다: “보안/권한 시스템을 살펴봤는데 원하는 것을 찾지 못했습니다. 기본적으로 순수한 Create 권한과 Create/Reply 권한은 존재하지 않습니다.” 아래에서 이 부분에 대해 다시 언급하겠습니다.

솔루션 #3: 그룹 인박스(Group Inboxes)

Sams의 원래 아이디어인 "Discourse를 개인 이메일 지원 포털로 사용하기"가 발전하여 그룹 인박스가 되었습니다. 그룹 인박스를 설정하고 지원 팀에 할당하면, 모든 사람이 인박스로 메시지를 보내거나 이메일을 보낼 수 있습니다.
이것이 현재 표준 솔루션이며 잘 작동합니다.

그러나, 저는 이 방식이 크게 마음에 들지 않습니다.

제 생각에는(!) 이 접근 방식에는 몇 가지 단점이 있으며, 주요 단점 3가지는 다음과 같습니다:

  • 지원 그룹으로 전송된 메시지를 찾기 어렵습니다(실제로 알림을 클릭할 대상이 없다면 모든 메시지를 찾기 어렵다고 생각합니다). 지원 스태프는 좋은 개요를 볼 수 있지만, 사용자는 그렇지 않습니다. 티켓을 처리하는 스태프 사용자는 별도의 그룹 인박스를 보는 반면, 티켓을 생성한 사용자는 자신의 ‘일반’ DM(개인 메시지) 사이에서 이를 찾아야 합니다.
  • DM의 태그 지원 부족: 스태프만 DM에 태그를 붙일 수 있으며, 사용자는 태그를 볼 수도 필터링할 수도 없습니다.
  • 메시지를 보낼 수 있는 '장소’가 없습니다. 지원 팀에게 메시지를 보낼 수 있는 기능은 어딘가에 명시적으로 홍보되어야 합니다(이것을 논리적인 장소에 두기 어렵고, 대부분의 경우某种 배너 형태로 끝납니다).

전체적으로, 제 경우에는 이는 카테고리 토픽과 DM 사이의 타협으로, 약간 ‘부착된’ 느낌입니다.

#4 비공개 토픽

이 아이디어는 여러 번 제안된 적이 있으며(또한 여기, 여기, 여기에서도 언급되었습니다), 위에서 'create’와 ‘create/reply’ 권한에 대해 이미 언급했습니다.

사람들이 토픽을 시작하고 지원 스태프(기본적으로: 그룹)와 상호작용할 수 있으며, 오직 그들과 해당 그룹 멤버만 토픽을 볼 수 있는 일종의 ‘드롭 박스’ 카테고리가 있다면 어떨까요?

그것은 이 사용 사례에 대한 골든 불릿이 될 것입니다. 모든 사용자가 자신의(그리고 오직 자신의만) 지원 티켓을 볼 수 있는 명확하게 정의된 ‘지원’ 카테고리를 가질 수 있습니다. 모든 것이 한 곳에 모여 있고, 태그 등 모든 기능을 사용할 수 있습니다.

하지만 @codinghorror와 @sam은 모두 토픽별 권한은 도입되지 않을 것이라고 여러 번 말해 왔습니다(많은 복잡성을 추가하기 때문에 완전히 이해합니다).

저는 두 가지 전진 방향을 봅니다: #3 그룹 인박스를 사용하고 그 단점들이 해결되기를 기다리거나, #4 비공개 토픽 아이디어에 다시 도전하는 것입니다.

그동안 토픽별 권한을 구현하는 몇 가지 플러그인이 등장했는데, 예를 들어 Restricted Replies - 카테고리에서 특정 그룹만 답변을 허용 - 과 Discourse Private Replies - 토픽 시작자(그리고 스태프)를 제외한 모든 사람에게 답변을 숨김 - 등이 있습니다. … 가능해 보이므로, 플러그인으로 이 아이디어에 다시 도전하는 것을 고려해 왔습니다.

하지만.

진행하기 전에 저는 다음 사항에 대해 듣고 싶습니다:

  • 그룹 인박스에 대한 제 의견에 동의하는 다른 사람이 있는지, 이러한 인식된 단점이 매우 주관적일 수 있다는 것을 알고 있기 때문입니다.
  • 비공개 토픽 플러그인 아이디어에 대한 (!!) 피드백
24개의 좋아요
2022: The Year in Review
New category permission: can post/reply, but not read
Private Topics Plugin
Using Form Templates in a private support capacity
4

정말 논의할 가치가 있는 좋은 주제입니다.

사적 회신(Private Replies)을 포크하여 아이디어에 맞는 무언가를 만들어낼 수 있을지도 모릅니다. 하지만 이를 위해서는 해당 분야에 정통한 사람이, 경우에 따라서는 스폰서십이 포함된 플러그인 포크를 위해 플러그인 개발자와 함께 논의해야 할 것입니다. 스폰서십이 있다면 크라우드펀딩 개념을 탐구하는 것도 좋은 기회가 될 것입니다.

그룹 메일박스(Group Mailbox)는 훌륭한 아이디어이지만, 제 생각에는 개인 메시지(PM) 시스템에는 쉽게 사용할 수 있는 검색 옵션이나 폴더 옵션을 활용한 그룹 북마크 기능이 필요합니다. 예를 들어, 클라이언트 A가 2020년 10월에 요청한 내용처럼요.

7개의 좋아요
5

원래 맥락을 알지 못했지만, 주제별 권한은 #4를 작동시키는 데 필요한 것보다 훨씬 더 광범위하고(말씀하신 대로 훨씬 더 복잡한) 전망인 것 같습니다.

제가 이 기능이 작동하는 방식을 상상하는 방법은 카테고리 권한에 '자기 주제 보기(See Own)'를 포함하도록 확장하는 것입니다. 현재 권한 구조와 유사하게, 추가된 그룹의 경우 ‘보기(See)’ 또는 ‘자기 주제 보기(See Own)’ 중 하나가 허용되어야 합니다.

'생성(Create)'을 허용하면 자동으로 '답글(Reply)'이 허용되듯이, '자기 주제 보기’를 허용하면 자동으로 '생성’이 허용되어야 합니다. 주제를 생성할 수 없는 상태에서 자신의 주제만 볼 수 있는 카테고리는 다소 무의미하기 때문입니다.

권한 영역에서 “단” 두 가지 추가 변경만 필요할 것 같습니다. 현재 사용자가 속한 그룹이 ‘자기 주제 보기’ 권한만 제공하는 경우:

  1. 주제 목록은 현재 사용자가 생성한 주제로 필터링되어야 합니다.
  2. 주제를 현재 사용자가 생성한 것이 아닌 경우, 해당 주제에 대한 접근이 거부되어야 합니다.

실제로는 최신 주제 목록과 같은 문제를 처리하는 데 추가적인 복잡성이 있을 수 있지만, 아마도(아마도…) 엄청난 양의 추가 작업은 아닐 것입니다.

저희는 현재 Discourse에서 비공개 지원을 제공하지 않으므로 firsthand 경험은 없지만, 제 자신의 인식은 여러분과 일치하는 것 같습니다.

발견 가능성(Discoverability)은 지원 요청을 어디서 해야 하는지 찾는 것뿐 아니라 현재 및 과거의 지원 문의를 검토하는 데에도 중요하며, 그룹 PM 방식에서는 이것이 잠재적으로 도전적일 수 있어 보입니다.

7개의 좋아요
6

피드백을 주셔서 감사합니다! 저는 해당 특정 플러그인의 작성자이며, 우리가 이것이 올바른 방향이라고 느끼면 (Communiteq) 이에 투자할 준비가 되어 있습니다. 따라서 그러한 것들은 문제가 되지 않을 것입니다.

네, 그 말씀이 맞습니다.

다만 *자기만 보기(See Own)*가 *만들기(Create)*를 의미하고, *만들기(Create)*가 *답글(Reply)*을 의미하며, *답글(Reply)*이 *보기(See)*를 의미하기 때문에, 이것이 정확히 어떻게 구조화되어야 하는지에 대해서는 여전히 조금 고민되고 있습니다.
하지만 우리는 *자기만 보기(See Own)*가 *보기(See)*를 의미하도록 하고 싶지는 않습니다.

8개의 좋아요
7

응, 그거 알아. 더 잘 챙겨봤어야 했는데.

:clinking_beer_mugs::smiling_face_with_sunglasses::vulcan_salute::sparkles:

5개의 좋아요
8

네, 생각보다 더 복잡한 문제인 것 같습니다. Reply 자체가 See를 함의하는 것이 아니라, 그룹이 카테고리 권한에 추가되는 행위 자체가 See를 함의하는 것으로 보입니다.

권한은 열거형(enumeration)이며, 그룹은 readonly, create_post, full 중 정확히 하나만 가집니다. 사용자가 특정 카테고리에서 답글을 작성하거나 주제를 생성할 수 있는지 확인하는 것은, 사용자가 (create_post 또는 full) 권한을 가진 그룹에 속해 있는 모든 카테고리 목록을 가져와 해당 카테고리가 그 목록에 포함되는지 확인하는 것과 (full) 권한을 가진 그룹에 속해 있는 모든 카테고리 목록을 가져와 해당 카테고리가 그 목록에 포함되는지 확인하는 것으로 귀결됩니다.

주제 생성은 간단합니다. 열거형에 full_own과 같은 추가 값을 추가하고, category.rb의 TOPIC_CREATION_PERMISSIONS 상수에 이를 추가하기만 하면 됩니다. 사용자가 해당 카테고리에 대해 full 또는 full_own 권한을 가지고 있다면 주제를 생성할 수 있습니다.

답글은 더 복잡하지만, 사용자가 full_own 권한을 가진 모든 카테고리를 반환하는 추가 스코프를 추가하는 것이 적절하다고 생각합니다. 다음과 같은 형태입니다:

  OWN_TOPIC_POST_CREATION_PERMISSIONS ||= [:full_own]
  scope :own_topic_post_create_allowed,  -> (guardian) { scoped_to_permissions(guardian, OWN_TOPIC_POST_CREATION_PERMISSIONS) }

그런 다음 post_guardian.rb에서 can_create_post?에 다음과 같은 추가 조건이 필요합니다:

    (!SpamRule::AutoSilence.prevent_posting?(@user) || (!!parent.try(:private_message?) && parent.allowed_users.include?(@user))) && (
      !parent ||
      !parent.category ||
      Category.post_create_allowed(self).where(id: parent.category.id).count == 1 ||
      (parent.is_my_own? && Category.own_topic_post_create_allowed(self).where(id: parent.category.id).count == 1)
    )

그러나 자신의 주제만 볼 수 있도록 하고, 이것이 관련 카테고리 페이지, 최신 글, 검색 및 기타 모든 곳에서 실제로 보장되는 것은 훨씬 더 도전적인 문제처럼 보입니다. 아직 해결 방법을 찾지 못했습니다.

6개의 좋아요
9

여기서 가장 손쉽게 해결할 수 있는 문제는 3번 문, 즉 로그인한 사용자에게 지원을 제공하도록 그룹 수신함을 개선하는 것이라고 생각합니다. 단순히 이메일로 지원을 요청하는 사용자뿐 아니라, 로그인하여 활동하는 사용자에게도 잘 작동하도록 말이죠.

그룹 수신함에 대한 주요 불만은 사용자 측의 기능 부족에 관한 것으로 보이며, 사용자가 티켓을 추적을 위해 로그인하고 사이트에서 다른 사람들과 개인 메시지를 주고받는다면 이는 정당한 요구입니다. 저는 메타(meta)에서 그룹 수신함을 사용하여 지원을 제공하는 과정에서 이를 많이 경험하지 못했습니다. 그룹 수신함을 통해 지원을 받는 대부분의 사람은 로그인하지 않고, 대부분 자신의 이메일을 사용하므로 우리와의 통신을 원하는 대로 정리하고 아카이브할 수 있습니다.

저는 메타에서 @support-teams를 통해 소통하는 몇몇 사용자와 연락하고 있으므로, 그들에게 이것이 어떻게 작동하는지 그리고 제안 사항이 있는지 물어볼 것입니다. 또한 이것이 실제로 어떻게 작동하는지 확인하기 위해 저 혼자서도 더 많은 테스트를 수행할 것입니다. 제 생각에 요청 사항은 다음과 같습니다:

  • 비직원 사용자에게 메시지 태그를 볼 수 있게 허용 (현재는 직원만 태그를 볼 수 있습니다. 비직원이 메시지에서 볼 수 있는 일부 태그를 제공하기 위해 태그 그룹을 사용할 수 있을까요? :thinking: )
  • 사용자가 그룹과 메시지를 주고받을 때, 사용자가 그룹과의 자신의 메시지를 볼 수 있도록 메시지 메뉴에 그룹 수신함으로의 링크 제공 (이것은 직원에게는 이미 작동하지만, 비직원에게는 어떻게 작동하는지 확실하지 않습니다. 수신함과 아카이브 사이에 문제가 있으며, 이는 사용자별로 개별적으로 제어되지 않습니다)
  • 그룹으로 새 메시지를 시작할 수 있는 링크 제공 (그룹 메시징이 허용되면 그룹 페이지에 이것이 존재한다고 생각합니다)

그룹으로 새 메시지를 시작하는 기능은 @support-teams 그룹의 일원으로서 Discourse for Teams 이메일 지원을 제공하는 제가 주목한 부분이기도 합니다. 지원 팀에서 새 메시지를 시작하려면 지원 팀과 작성하려는 사람의 이메일 주소를 모두 포함해야 합니다. 이는 다소 번거롭습니다.

또한, 그룹 수신함을 사용하는 방식에 따라, 메시지가 해결되면 주제처럼 메시지를 닫지 않고 아카이브합니다. 이렇게 하면 해결된 메시지를 우리 시야에서 치울 수 있을 뿐만 아니라, 고객이 이메일로 후속 조치를 취하여 메시지를 다시 수신함으로 이동할 수 있도록 허용합니다.

5개의 좋아요
10

저는 이 점을 충분히 고려하지 못했는데, 꽤 흥미로운 지적입니다. 이메일 지원에서는 고객이 오래된 이메일을 찾아서 새 이메일을 보내는 대신 해당 이메일에 답장을 보내는 경우가 매우 흔합니다. 만약 토픽이 닫혀 있다면, 고객이 이메일이 거부된 것을 발견할 때 적어도 혼란을 겪을 가능성이 높습니다.

4번 문 뒤의 상황(어떤 방식으로든 그 상황이 발생한다면)에서는, 토픽을 닫을 수 없다면 처리되지 않은 토픽을 식별하는 것이 직원 측에서 어려울 것입니다. 특히 지원 직원의 수가 많을 경우 더욱 그렇습니다. ‘Solved’ 플러그인도 이 부분에서 큰 도움이 되지 않을 것입니다. 고객이 오래된 토픽에 답장을 보낼 수 있고, 다양한 지원 직원들이 해당 토픽이 처리가 필요한지, 아니면 이미 다른 직원이 해결한 것인지 알 수 없기 때문입니다.

6개의 좋아요
11

full, create_post, readonly를 수정하는 것이 올바른 방향인지 확신이 서지 않습니다. full과 create_post는 여러 곳에서 "모두 보기"를 의미하기 때문이죠. 그렇게 하면 유지보수 가능한 플러그인을 만드는 것이 쉽지 않을 것입니다. 또한 직관적이지 않을 것 같다는 생각도 듭니다.

게다가 토픽 작성자가 해당 토픽에 추가 사람들(예: 동료)을, 예를 들어 멘션을 통해 추가할 수 있다면 좋겠습니다. 하지만 현재 이 메커니즘만으로는 이를 충족시키기 어렵습니다.

현재 제 생각은 권한을 그대로 두면서 보안 그룹 아래에 섹션을 추가하는 것입니다:

이 카테고리에서 비공개 토픽 활성화
다음 그룹이 모든 토픽을 볼 수 있도록 허용 [x 지원 스태프] [x 영업 지원]

저는 비공개 답변 플러그인에서 비슷한 작업을 수행했습니다. 다만 카테고리 내 토픽이 아니라 토픽 내 게시물에 대한 것이었습니다.
TopicGuardian에 몇 가지 패치를 적용하면 꽤 멀리 갈 수 있을 것 같습니다.

네, 그건 정말로 손쉬운 과제일 수 있습니다. 제 요청 사항에 대한 요약은 정확합니다. 그리고 메시지가 토픽과 더 잘 조화를 이루게 해줄 것 같은 두 가지 더 발견했습니다.

  • 포럼을 검색할 때 제 메시지를 검색하려면 검색 쿼리에 명시적으로 in:private을 추가해야 합니다. 때로는 어떤 것이 (더욱 공개적인) 토픽이었는지, 아니면 그룹으로 보낸 개인 메시지(PM)였는지 기억이 잘 나지 않습니다. 왜 기본값으로 포함하지 않을까요?

  • 또한 햄버거 메뉴의 오른쪽 탭에 메시지로 가는 간단한 링크가 있으면 좋겠습니다. 네, 봉투 아이콘은 있지만, 그것은 메시지 목록을 보여주지 /my/messages 메시지로 가는 링크가 아닙니다. 그 화면은 숨겨져 있는 것 같습니다.

드롭다운의 항목들은 다음 화면의 탭과 일부 중복되지만 **Messages(메시지)**와 **Badges(배지)**를 제외하고는 그렇습니다. 그래서 제 메시지로 갈 때마다 항상 Summary(요약)를 클릭한 다음 Messages(메시지)를 클릭해야 합니다.

드롭다운의 항목들을

image
image334×312 7.34 KB

프로필 화면의 탭들과 비교해 보세요

image

양쪽에 Summary, Activity, Invites, Preferences가 있지만 한쪽에는 Drafts가 있고 다른 쪽에는 Notifications, Messages, Badges가 있습니다. 그래서 저에게는 "Messages"가 매우 숨겨져 있는 것처럼 느껴집니다 (Notifications와 Badges도 마찬가지지만, 저는 그것들을 그렇게 자주 사용하지는 않습니다).

7개의 좋아요
12

좋은 지적입니다. 이 장벽 뒤에 어떤 고찰이 있는지 정확히 모르겠습니다. 또한, 메시지 화면에 있을 때 기본적으로 in:personal이 추가되는 것을 확인했는데, 이건 좋습니다! 하지만 예를 들어 in:support-teams를 추가하여 그룹 받은편지함의 메시지만 검색할 수는 없는데, 이는 좋은 아이디어라고 생각합니다. 고급 검색에서도 제가 아는 한 그룹 받은편지함으로 필터링하는 쉬운 방법이 없습니다. (cc @pmusaraj)

Screen Shot 2022-01-19 at 12.08.43 PM
Screen Shot 2022-01-19 at 12.08.43 PM535×179 13.5 KB

좋은 아이디어이지만, 그 드롭다운 메뉴의 공간(real estate) 문제가 있다고 생각합니다. 그 목록에 7개 이상의 항목을 넣기는 원하지 않을 것입니다. 또한, 대부분의 커뮤니티에서는 실제로 메신저 사용을 장려하고 싶지 않다고 생각합니다. 사람들이 공개적으로 대화하길 원합니다! 메시지에서 대화하는 사람들을 위해, 알림 드롭다운과 이메일 알림 등은 주의를 요하는 메시지에 적시에 접근할 수 있는 충분한 수단을 제공합니다.

그럼에도 불구하고, 우리는 메뉴 시스템 개선(키워드: sideburger)에 적극적으로取り組んでいます. 따라서 이 문제를 고려에 포함하겠습니다. Discourse for Teams의 사이드바는 이미 그룹 받은편지함과 관찰 중인 태그에 즉시 접근할 수 있는 기능을 제공하며, 이는 sideburger 프로젝트와 함께 코어 Discourse에도 가져올 수 있습니다.

다음은 제 Discourse for Teams 사이트에서 Kabissa 그룹 받은편지함에 있을 때 현재 보이는 모습입니다:

Screen Shot 2022-01-19 at 12.15.36 PM
Screen Shot 2022-01-19 at 12.15.36 PM234×304 4.45 KB

5개의 좋아요
13

그룹을 지원 그룹으로 지정하고, 이 지정 여부에 따라 햄버거 메뉴 항목을 생성하는 것에 대해 고민 중입니다. 상태는 다음과 같습니다:

  • 지원으로 지정된 그룹이 0개일 때: 메뉴 항목 없음
  • 지원으로 지정된 그룹이 1개일 때: 해당 그룹으로 메시지를 시작하는 “지원에 메시지 보내기” 항목
  • 지원으로 지정된 그룹이 1개 이상일 때: “지원” 항목으로, 그룹 페이지와 유사하게 모든 지정된 그룹과 메시지 보내기 버튼을 표시하는 페이지로 링크

아마도 추가적인 메뉴 항목과 페이지는 과할 수 있습니다. 소개 페이지에 생성된 추가 섹션을 추가하는 것은 어떨까요?

전혀 명확하지는 않지만, 이것은 메시지 탭에 있습니다. 메시지 목록 하단의 아래쪽 화살표는 /my/messages 화면으로 이동합니다. 요약에서 메시지로 가는 것보다 클릭 수는 같지만 페이지 로딩은 한 번 적게 발생합니다.

만약 제가 Kabissa로 메시지를 보내는 사용자라면, 해당 토픽은 어떤 방식으로든 주로 그룹과 연관되나요, 아니면 토픽에 액세스가 허용되는 것이 제 사용자와 Kabissa 그룹뿐인가요?

만약 그룹과 주로 연관된다면, 제 메시지 페이지에 Kabissa 받은 편지함을 동일한 방식으로 표시하는 것이 실현 가능할까요? 물론 제가 액세스할 수 있는 메시지만 포함되겠지만요.

6개의 좋아요
14

여기서 메타 환경에서 테스트를 해보았는데, tl0 사용자를 생성한 후 support-teams 그룹 페이지로 이동하여 메시지 버튼을 선택하여 그룹에 메시지를 보낼 수 있었습니다. 메시지를 게시한 후에는 내 보낸 메시지 폴더에 저장되었습니다. 따라서 기능은 정상적으로 작동하지만, 일부 경우에는 접근성이 다소 낮을 수 있습니다. 사이트의 목적에 맞게 햄버거 메뉴에 링크를 추가하거나, 홈페이지에 배너를 배치하는 등 자유롭게 구성할 수 있습니다. 따라서 여기서 더 해야 할 일이 많다고 보기는 어렵지 않나요?

해당 스크린샷에 표시된 Kabissa 수신함은 Kabissa 그룹에 속한 사람들에게만 표시됩니다. Kabissa에게 메시지를 보내는 사용자는 해당 메시지를 자신의 메시지 목록에서 확인할 수 있습니다.

5개의 좋아요
15

in:all이 존재한다는 점에 유의하세요. 이 옵션을 사용하면 공개 내용과 개인 내용을 한 번의 검색으로 모두 확인할 수 있습니다.

기억이 정확하다면, 이 아이디어는 개인 메시지와 공개 주제 사이의 분리 강제를 통해 무엇이 공개적이고 무엇이 개인적인지에 대한 혼란을 최소화하기 위한 것이었습니다. 다만, 그룹 수신함은 이러한 분리를 상당히 흐릿하게 만듭니다.

8개의 좋아요
16

지원(고객지원) 관련 그룹의 발견 가능성을 높이는 방향으로 생각하고 있었습니다. 단일 지원 그룹을 가진 커뮤니티의 경우(실제로 제 목적에는 이상적입니다) 햄버거 메뉴에 링크를 추가하는 것이 적합하지만, 여러 지원 그룹을 가진 커뮤니티라면 지정된 그룹을 위해 소개 페이지에 페이지나 섹션을 생성하는 것이 더 이롭습니다.

돌이켜 보면, 커뮤니티가 이를 필요로 한다면 플러그인으로 구현하는 것이 더 적합할 것 같습니다.

아마도 부끄럽게도 질문을 잘못 표현한 것 같은데, 현재 모델이 사용자가 소속되지 않았지만 상호작용하는 그룹에 대해 필터링된 수신함을 표시할 수 있도록(미래에) 충분한 정보를 가지고 있는지 묻고 싶었습니다. 이는 @RGJ 님이 언급한 대로 그룹으로 보낸 메시지를 찾기 어렵다는 우려와 관련이 있습니다.

예를 들어, Teams용 Discourse 사이트에서 일반 사용자인 제가 Kabissa 그룹에 보낸 모든 메시지(아마도 제가 참여 중인 메시지)를 보여주는 Kabissa 수신함을 내 메시지 목록에서 볼 수 있는 경우를 말합니다.

제 추측으로는 그렇지 않은 것 같습니다. 아마도 단순히 참여자 목록만 가지고 있으며, 이는 사용자나 그룹 수와 관계없이 어떤 것이든 될 수 있기 때문입니다.

7개의 좋아요
17

이것이 점점 더 인기를 얻고 있다는 점은 정말 좋습니다! 그 이유는 Discourse가 사적인 지원 티켓 시스템으로 훌륭하며, 제대로 작동할 때 정말 놀랍도록 잘 작동한다고 생각하기 때문입니다.

제가 Discourse가 원래 설계된 용도가 아님을, 그리고 Discourse가 해야 할 일이 아닌 일을 억지로 시키고 있음을 잘 알고 있습니다. 하지만 개인적인 받은 편지함(private in-boxes)과 메인 토픽의 모든 화려함과 기능을 비교한다면, 저는 매일 후자를 선택할 것이며 계속 억지로 끼워 맞추는 시도를 이어갈 것입니다…

4개의 좋아요
18

우리는 이 부분을 지원하기를 원합니다(비유적으로도, 문자 그대로도). 하지만 우리가 '지원 도구’라는 구석으로 몰리는 것은 원하지 않습니다. :wink: 디스코스가 이 역할을 더 잘 수행할 수 있도록 하는 구체적인 피드백이 있다면 알려주세요.

우리는 항상 경청하고 있습니다 :ear::hugs:

8개의 좋아요
19

좋은 아이디어네요! 우리 커뮤니티에서도 사용자 수신함과 별도로 지원 티켓을 관리해 달라는 요청이 있습니다. 사용자가 자신의 티켓만 볼 수 있는 이러한 카테고리가 있다면 정말 유용할 것입니다.

4개의 좋아요
20

감사합니다!

우리는 사적인 지원을 위해 PM(개인 메시지) 그룹을 사용하고 있으며, 잘 작동하고 있습니다. 지원 시스템을 많이 사용하는 사용자들의 주요 불만은 자신의 메시지를 검색할 수 없다는 점입니다.

우리는 사용자에게 메시지를 검색하려면 검색 쿼리에 in:personal 코드를 추가해야 한다고 가르치려 노력해 왔지만, 직관적이지 않고, 솔직히 말해서 실제로 이 방법을 성공적으로 수행하는 사용자를 단 한 명도 본 적이 없습니다. 그들은 그냥 포기하고 자신의 메시지를 검색할 수 없다고 불평할 뿐입니다.

검색창 아래에 있는 이 "제안"이 무엇에 사용되는지조차 이해하지 못합니다.

image
image540×119 1.78 KB

고급 검색으로 이동하면 ‘메시지 검색’ 라디오 버튼을 선택할 정도로 숙련되어 있을 수 있지만, 그 버튼이 in:personal이라는 단어를 추가하게 되면 모든 것이 이상해 보이기 시작하여 그 지점에서 포기해 버립니다.

검색창에 코드를 추가하지 않아도 되는 훨씬 더 직관적인 메시지 검색 방법이 있다면, 그것은 큰 개선이 될 것입니다.

그렇지 않다면, 예를 들어 "in:messages"와 같이 더 직관적인 언어를 사용하는 것만으로도 약간의 개선이 될 것입니다.

6개의 좋아요
21

아니면 검색에 기본적으로 pms를 포함하도록 하는 건 어떨까요?

4개의 좋아요
22

정말 그렇네요 — 그게 정말 좋을 것 같아요!

기본적으로 꺼져 있는 “기본적으로 PM 검색” 설정이 있으면 정말 이상적이겠습니다.

이렇게 하면 일반 주제와 PM 주제 검색 결과 사이에서 혼동을 겪을 수 있다는 우려(저는 그런 문제가 없지만)와 아예 PM 주제를 검색할 수 없다는 문제(저는 이 문제가 있습니다) 사이의 균형을 맞출 수 있을 것 같아요.

3개의 좋아요