Use Discourse as a Private Support/Ticket System

[schungx (Stephen Chung)]

On and off I’ve seen posters asking about how to use Discourse as a support (or ticketing) platform. I’d like to share my setup here for those with similar needs.

Background

You run/work for an organization. You need to provide pre-sales, after-sales, technical and/or one-on-one support to your customers, agents, distributors and/or partners (which organization doesn’t?).

What is Discourse

Discourse is primarily a forums software, geared towards public, open conversations of various topics. It is incredibly modern and performant, runs at lightning speed, and you have a lot of flexibility in how to setup your environment.

You want to see if you can coerce this fabulous piece of software to do what it isn’t originally designed to do.

Prior Art

• Configuring incoming email to create new topics or group messages
• Discourse as a private email support portal
• Set up reply by email with POP3 polling
• Private Topics - are they supported?
• Using discourse as a community ticket system
• How to optimize issue/support ticket like workflow?
• Can incoming Discourse email support replace old ticket portals?
• Create/See and Create Permissions (again)

What You Want

Your customers will open issues, or help tickets, on the system. They either open it under their own folder/category, or you can have some systematic/manual way of reclassifying them later on.

There may be sensitive things discussed, so by default you don’t want each customer to be able to see the issues or inquiries raised by other customers. In other words, each customer conversation should be private.

You want your support teams to each work on their allocated areas/categories. In other words, your teams should be able to see a list of all the support requests in their own categories, and be able to easily sort through them, manage them and follow-up on them without a lot of searching and filtering.

Some information may be sensitive, so each team’s area may be separated from another team’s, so they cannot view each other’s data.

Note: This method assumes that you are creating a dedicated ticketing platform, or that at the very least there will be no overlap between the users of your Discourse web interface and those requesting support tickets.
In the event that you might need to support users who are already on the same instance, consider instead using private messages to a group, and configure inbound email for the group inbox.

Your Problem

1. Some core features are geared towards an open community, and may not be relevant to a private support forum, for example the badges.

2. You looked at the security/permissions system and you don’t find what you want: basically pure Create and Create/Reply permissions do not exist.

3. Your customers don’t really want to go through the hassle of creating an account on your forum just to ask a support question. But you also don’t want to open up your forum to the public and have silly posters come in and waste your time.

   You want a way to detail with these one-off inquiries quickly, but leave open the possibility of maintaining a long-term relationship with certain customers.

4. A lot of your customers work with emails, and you want to reply to them via email, but you also want your support teams to be able to manage these requests quickly and easily without digging through piles of email.

How it Will Work

• You have a bunch of email addresses published for customers to send inquiries. For example, you may have an email address called wonderful_product@support.example.com for people to send questions regarding the Wonderful Product product line of your company.

• A customer sends an email to this address.

• The email is automatically turned into a topic in the appropriate Wonderful Product category.

• A staged user (say, MrFoo) with no rights is created on the system to track all the requests sent by that email.

• You internal team support staff, under the group WonderfulProductTeam, which has Reply/See permission on the Wonderful Product category, sees the topic and post replies.

• Each reply turns into a reply email back to the originating customer.

• The customer feels that his/her email is being replied personally.

• The customer has no way to see the emails of any other customer on the system. Meanwhile, the WonderProductTeam sees all the emails sent to wonderful_product@support.example.com all together in a single list.

• You find that user MrFoo has been a great contributor and would actually like to involve him into your support pipeline. Go to his user profile and send him an invitation to become a member. Put him in an appropriate Group with appropriate access rights.

• MrFoo, now an valued member of your support organizatio, logs in and sees all his previous emails neatly under his account.

Setup Instructions

Basic Discourse setup

• Turn off Settings|Basic Setup|enable badges because badges are not awarded for posts in non-Everyone categories, which most of your categories will probably be. They will just confuse your users. Keep it if you have large, open-to-all-users categories.

• Turn on Settings|Basic Setup|enable whispers if you want whispers. This may be useful when you have many moderators.

• Turn on Settings|Login|invite only unless you want to allow customers to self-register themselves. You may not want the hassle.

• Turn on Settings|Login|login required because you are not running a public forum.

• Set Settings|Trust Levels|default trust level to 0 to make sure staged users created via email is level 0.

• Set Settings|Trust Levels|default invitee trust level to 1 to make sure that the users you actually want to be on the system are level 1.

• Turn on Settings|Email|enable staged users

• (Optional) Settings|Login|must approve users may not be necessary if your forum runs on invitation only.

• (Optional) Set Settings|Posting|approve new topics unless trust level to 1 so that your staged users (which will be created as level 0) will have their topics pending staff approval.

  Note: As of 1.9.0beta13 this doesn’t work because topic approvals by-pass all staged users. This may be corrected in the future.

• Turn off SSO because you obviously don’t want any unknown persons to sign into your forum.

Set Up the Appropriate Email Addresses

• On your email system, setup a MASTER mail-in email account, for example: master@support.example.com.

• For each area/team/category, create a new, specific email account, for example: wonderful_product@support.example.com.

• FORWARD all emails to those specific accounts to the MASTER email account. For example, an automatic forwarding should be created to forward all mail received by wonderful_product@support.example.com to master@support.example.com.

Turn on email in

• Turn on Settings|Email|reply by email enabled

• Turn on Settings|Email|email in

• Turn on Settings|Email|pop3 polling enabled

• (Optional) Turn on Settings|Email|pop3 polling ssl if your POP3 email server requires SSL.

• (Optional) Turn on Settings|Email|pop3 polling openssl verify if your POP3 server uses SSL.

• Turn on Settings|Email|reply by email enabled

• Set Settings|Email|reply by email address to the MASTER email account in the section above (for example: master@support.example.com).

• (IMPORTANT) If your email system does NOT support the + feature, then turn off Settings|Email|find related post with key. This will use each email’s In Reply To header to find the correct thread, with certain security considerations.

• Set Settings|Email|pop3 polling host, pop3 polling port, pop3 polling username, pop3 polling password for your POP3 email server. The username and password should be for the MASTER email address.

• Set Settings|Email|email in min trust to 0 because your staged users will be created with trust level 0.

• Set Settings|Email|maximum staged users per email to a small number unless you have a good reason to allow creating large number of staged users from an email.

• Set up suspected SPAM email domains in Settings|Login|blocked email domains. This prevents emails from unwanted domains from creating staged users in your forum and littering them with SPAM topics.

  Notice that regexp expressions work in this, EXCEPT for the dot (.). You do NOT need to escape the dot because it will be automatically escaped. In other words, \d+\d\d\d.\w+ will actually be \d+\d\d\d\.\w+$ and will match any domain that is a string of digits more than 3 long plus a root domain (.com, .org etc.).

• Set up suspected SPAM email subjects in Settings|Email|ignore by title. This prevents emails with suspicious subjects from creating topics.

  Notice that regexp expressions work in this. Wrap your entries with \b if you want to match whole words in English. BEWARE, \b works for English language only!!!

Attachments

• Add allowed attachment formats in Settings|Files|authorized extensions because customers who requires support will typically send in attachments other than photos (maybe a PDF file, an Excel spreadsheet, a CAD drawing, an error log file, or a zip file).

• Set Settings|Files|max attachment size kb large enough so that reasonable attachments do not bounce. Typically 1MB to 2MB is enough.

Set Up Email Info in Categories

• For each category that will receive emails from outside, set Custom incoming email address (in the Settings of the Edit dialog of that particular category) to the appropriate email account.

  For example, in the Wonderful Product category, press Edit and go to the Settings tab. Custom incoming email address should be set to wonderful_product@support.example.com. Then, all emails sent to wonderful_product@support.example.com will be created as topics in this category.

• Turn on the Accept emails from anonymous users with no accounts setting for each category that will receive emails.

Set Up Security in Categories

• Remove the Everyone group from each category’s access list.
• Use Groups to manage access to each category.

If You Have a Multi-Lingual (Worldwide ) Customer Base

• Turn on Settings|Basic Setup|allow user locale

• Turn on Settings|Basic Setup|set locale from accept language header

  Notice that it doesn’t work for redemption from invitations as of 1.9.0beta13.

• Consider the discourse-translator plugin

• If you have Chinese users, please make sure to search meta for the settings required to support Chinese language posts.

[Walker_Blackwell]

@schungx

Turn on the Accept emails from anonymous users with no accounts setting for each category that will receive emails.

I think I’ve found a minor bug with this and am interested in other’s opinions. I’ve set up everything just about exactly like these instructions however I have a email-receiver docker running to receive emails directly at my hosted discourse forum and send to the forum via API. This is better than POP3. Email server forwards emails from help@test.com to help@myforum.test.com which is set up as the category incoming email. All good and fine. When I send an email to help@test.com with a nonregistered email accout it creates a new ticket/topic in the thread and I can handle that.

The problem comes after I’ve invited the user to become a member of the forum. When they are anything OTHER than anonymous or staged they suddenly can’t sent a support request email to help@test.com. The email gets rejected because the category is restricted to admins only for see/replying/posting AND to anon/staged (0-level) users for posting.

There is no way to allow for a level 1,2,3 user to POST/EMAIL to the category without actually seeing the category and all the other topics available correct? At least I don’t see how to fix this.

tldr: the second a user is no longer level-0 (when email-receiver is the way incoming email is handled) they can’t email to create a new support ticket.

It’s almost like this needs to be toggles so Create/Reply can be set but not See.

How to fix?

[Dannii]

I just had this same problem. The conclusion is that you should only use a category if the forum is closed to general registrations and the only users will be staff. Otherwise you should instead have a group set to receive emails. That is detailed here. I’ll edit this howto to warn against what we’ve both tried.

[Stephen]

I don’t think your edit makes much sense. The title is ‘How to use Discourse as a Private Support/Ticket System’ while you’re both trying to use Discourse as a community and a ticketing system. That’s not the same thing by any stretch of the imagination.

[Dannii]

What exactly is wrong with the edit? I’m clarifying that you shouldn’t use a category to receive emails unless the whole forum is private. Handling the contact email address within a community forum must be a common desire, but it won’t work with category email in. I misunderstood the implications of this howto, and so edited it to help others like me and Walker avoid making the same problem in the future.

[codinghorror (Jeff Atwood)]

@Dannii

you shouldn’t use a category to receive emails unless the whole forum is private

I think that’s a fine clarification.

[schungx (Stephen Chung)]

I would think it is very strange for your setting.

Now, why would you:

1. Just anybody ==> email in and start a topic
2. Registered user ==> email in and start a topic
3. Registered user ==> start topic in browser NOT ALLOWED

To me it makes no reasonable sense. You’re allowing anybody on the street to start a topic in that category. Why would you ever want to prevent your registered users to do the same (which is to start a topic)?

The method that they start a topic (via browser vs. via email) should not affect their ability to start a topic.

The behavior in Discourse is absolutely logical and it should be this way. Staged users (i.e. from emails) are created by the system and they cannot login; and since they are created automatically, you don’t really give them specific permissions.

Note: I’m not considering the fact that you can make normal users all trust_level_1 and staged users trust_level_0 then disallow topic creation for trust_level_0. I have not tried it to see what happens…

Now, registered users fall under normal permissions control, and if you disallow a user from starting topics in a category, the system should disallow him/her from starting a topic REGARDLESS of the method (i.e. email or via browser).

[schungx (Stephen Chung)]

However, I do second (strongly) your suggestion to create Create/Reply as a separate permissions tier.

There was a lengthy discussion on this a long time ago:

Create/See and Create Permissions (again)

Continuing the discussion from "Create" Permission: Now that the “whisper” functionality (https://i.imgur.com/orfu6df.png) has been added to Discourse, I feel like this topic should have new life breathed into it again. This proposal is for two new permission sets: Create, and Create/See. Both of these could be used in “fringe” forums where confidentiality or experience is required. These won’t be used on all the Discourse forums in existence, but the ones that could/want to use something li…

As I mentioned in that discussion, Create/Reply will be ideal for a secured support-ticket system where you don’t want everybody to be able to see other people’s tickets.

[Walker_Blackwell]

My original question above was a bit naive as I had not properly understood group message dynamics. The group incoming email/post system works perfectly and essentially is exactly what I/we need simply in a Group instead of Category (there isn’t much difference there really).

New on-boarded support staff with access to the support group(s) have access to the historical ticket archive by simply going to /g/[thegroupname]/messages/inbox which is essentially a category topics list.

As a side note for those interested I set the pre-foward incoming email system (help@test.com) to auto-reply a canned “thank you for your question” type email. Then the email is sent to the email-receiver to create the post. This keeps the customers calm and not posting a second time and gives me a bit of time to work the ticket response.

best,
Walker

[tknospdr (David Muszynski)]

이 글만큼 잘 쓰인 글이 표준 온라인 커뮤니티 그리고 티켓팅 시스템으로 Discourse를 사용하려는 분들을 위해 존재할까요?
도움말 티켓 사용자와 커뮤니티 포럼 사용자 사이에 절대적으로 중복이 있을 경우 말입니다.
이것이 수레바퀴 한 가득의 주의사항 없이 가능할까요?

[merefield (Robert)]

이러한 유형의 사용 사례(그리고 그 외에도 많은 경우)를 위한 옵션으로, 다음과 같은 플러그인을 작성했습니다:

Process Manager - 이전 이름 "Discourse Workflow"

요약 Discourse용 프로세스 관리 플러그인으로, 작업이 구성 가능한 단계를 통해 진행되며 액션, 목록 필터, 차트, 스윔레인 뷰 및 칸반 보드를 지원합니다. 레포지토리 링크 https://github.com/merefield/discourse-process-manager 설치 가이드 Discourse에 플러그인 설치하는 방법 이 플러그인을 즐기고 계신가요? GitHub에서 를 눌러주세요! [정장 차림의 사람이 테이블에서 펜으로 종이에 쓰고 그래프를 가리키고 있는 모습. (AI 캡션)] 요약 Process Manager는 Discourse를 위한 안전한 프로세스 관리 프레임워크를 제공합니다. 각 프로세스는 구성 가능한 단계와 옵션으로 구성되며, 토픽은 완료될 때까지 이러한 단계를 거칩니다. 프로세스는 워크플로, 승인 흐름, 지…

이를 카테고리(및 하위 카테고리)에 설정하고, 권한을 설정하여 메인 커뮤니티의 시야에서 제외할 수 있습니다.

[tknospdr (David Muszynski)]

정보 감사합니다. 이 글과 플러그인을 통합해서 초보자들도 쉽게 설정할 수 있는 ‘How To’ 기사가 있을까요?

[nathank (Nathan Kershaw)]

다른 옵션은 Communiteq 팀이 개발한 이 검증된 플러그인입니다:

개인 토픽 플러그인

Summary Private Topics Enables private topics in a regular category Repository Link GitHub - communiteq/discourse-private-topics · GitHub Install Guide How to install plugins in Discourse Features This plugin allows you to add an extra security setting to categories so that users can only access their own topics. You can also designate one or more groups that can see all topics in the category. This is typically used for…

이 플러그인은 위에서 언급한 문제를 훌륭하게 해결해 줍니다.

[tknospdr (David Muszynski)]

네, 이 방식은 이 게시물의 본문에서 설명한 대로 시스템에서 주로 "티켓"을 생성할 예정인 단계별 사용자와 함께 작동하는 것이 맞나요?

[mcwumbly (Dave McClure)]

여기 Discourse에서 메타 커뮤니티를 이렇게 활용하고 있다는 점도 공유하겠습니다.

고객이 이메일을 보내면, 여기서 설명된^[1] 대로 카테고리로 보내지는 대신, 티켓팅 시스템으로 사용하는 그룹 공용 수신함에 개인 메시지(PM)가 생성됩니다. 수신함 뷰에 이를 돕기 위해 경량화된 꾸밈을 조금씩 추가해 왔지만, 대부분은 내장 기능을 사용하고 있습니다.

우리의 워크플로 핵심은 1) 지원 팀의 누구든 응답할 수 있는 그룹 수신함을 사용하는 것, 2) 최신 응답을 처리한 후 PM을 아카이브하는 것입니다.

고객이 답장을 보내면 아카이브된 PM이 자동으로 수신함으로 다시 돌아와 전체 팀이 다시 볼 수 있습니다.

팀은 이러한 PM에 속삭임(whisper)을 사용하여 서로 협업할 수 있으며, 최근에는 AI 속삭임도 실험하기 시작했습니다. 이를 통해 초기 조사 결과를 팀 전체에 미리 공유합니다.

---

1. 특정 경우에는 비공개 카테고리를 사용하기도 하지만, 이제는 예외적인 경우이며, 그룹 수신함 워크플로가 우리의 표준이 되었습니다. ↩︎

[tknospdr (David Muszynski)]

@schungx

FORWARD 모든 이메일을 해당 특정 계정에서 MASTER 이메일 계정으로 전달하세요. 예를 들어, wonderful_product@support.example.com으로 수신된 모든 메일을 master@support.example.com으로 전달하도록 자동 전달 설정을 만들어야 합니다.

이메일 계정당 요금을 지불해야 하는 우리들을 위해, 단일 마스터 지원 계정을 만들고 해당 계정에서 개별 주소의 별칭(aliases)만 생성할 수 있을까요?

현재 제 메인 계정에는 12개의 별칭이 있는 것 같습니다. 일부는 심지어 도메인 이름이 다른 경우도 있습니다. 그 주소들 중 어디로 이메일이 보내져도 제 실제 계정으로 전달됩니다.

이 목적에 그렇게 하면 될까요?

[tknospdr (David Muszynski)]

@Walker_Blackwell

문제는 사용자가 포럼 멤버로 초대된 후에 발생합니다. 사용자가 익명(anonymous) 또는 대기(staged) 상태가 아닌 경우, 갑자기 help@test.com으로 지원 요청 이메일을 보낼 수 없게 됩니다. 해당 카테고리는 관리자만 보기/답글/게시 가능하고, 익명/대기(0레벨) 사용자는 게시만 가능하도록 제한되어 있기 때문에 이메일이 거부됩니다.

1, 2, 3레벨 사용자에게 카테고리를 실제로 보고 다른 모든 주제에 접근할 수 있게 하지 않으면서도 해당 카테고리에 게시/이메일을 보낼 수 있도록 허용하는 방법이 없나요? 적어도 저는 해결 방법을 찾지 못했습니다.

이 질문이 매우 오래된 것임을 알고 있지만, 다른 답변을 찾지 못했고 해결책을 알고 있다고 생각합니다. 적어도 제 환경에서는 작동합니다. 저는 이제 막 시작하는 단계라 이렇게 하면 의도하지 않은 결과가 생길지 모르지만, 방법을 공유합니다.

카테고리와 그룹의 개념을 좋아해서 이 설정 가이드를 따르고 있었지만, 동시에 개방형 포럼을 원했고 위에서 언급한 동일한 문제에 부딪혔습니다.

관리자 화면에서 email settings in을 검색하면 아래 페이지를 찾을 수 있습니다. 여기에는 사용자가 이메일을 통해 게시물을 생성하려면 신뢰 레벨 2가 필요하다는 내용이 표시됩니다.

대기 상태 사용자는 이 요구 사항을 우회하지만, 완전한 사용자가 되더라도 여전히 신뢰 레벨 0이므로 이메일 기능이 깨집니다. 따라서 TL2를 제거하고 TL0를 추가하면 됩니다.

이 작업을 수행하고, 위에서 링크된 Private Topics 플러그인을 함께 사용하여 사용자가 웹사이트에서도 직접 지원을 요청할 수 있도록 했습니다. 이제 거의 마무리 단계입니다.

우선순위와 상태 태그를 깔끔하게 통합하면 준비가 완료될 것 같습니다.

[RGJ (Richard - Communiteq)]

@Walker_Blackwell

문제는 사용자를 포럼 멤버로 초대한 후에 발생합니다. 사용자가 익명(anonymous) 또는 대기(staged) 상태가 아닌 경우, 갑자기 지원 요청 이메일을 보낼 수 없게 됩니다 […] 해당 카테고리가 관리자(admins)만 보기/답장/게시할 수 있고, 익명/대기 상태의 사용자만 게시할 수 있도록 제한되어 있기 때문에 이메일이 거부됩니다.

@tknospdr

위에서 링크된 Private Topics 플러그인을 함께 사용했습니다.

네, 바로 그 플러그인이 그런 용도로 만들어졌습니다!

[nathank (Nathan Kershaw)]

Private Topics 플러그인은 이 용도에 매우 훌륭하지만, 한 가지 중요한 약점이 있습니다. 바로 각 주제(Topic)당 단 한 명의 사용자만 허용할 수 있다는 점입니다. 이는 해당 카테고리 내의 모든 주제를 다른 사용자에게 노출시키지 않고는 그 주제에 다른 사용자를 추가할 수 없다는 것을 의미합니다.

해결책은 해당 주제를 개인 메시지(PM)로 변환하거나, 적절한 경우 더 공개적인 위치로 이동하는 것입니다. 하지만 특정 주제에 접근할 수 있는 다른 사용자(또는 그룹)를 지정할 수 있다면 훨씬 좋겠습니다. 다만, 이를 구현하려면 꽤 복잡한 솔루션이 필요할 것 같습니다.

@mcwumbly

우리의 워크플로우에서 핵심적인 부분은 1) 지원 팀의 누구든 응답할 수 있는 그룹 인박스(group inbox)를 사용하고, 2) 최근 응답을 처리한 후 개인 메시지를 아카이빙하는 것입니다.

이 용도에 개인 메시지 시스템을 사용하는 것은 매우 강력하고 유연하며(다른 사용자를 끌어들이는 것도 가능하지만), 동시에 중요한 약점이 있습니다. 바로 포럼 본체와 격리(silo’d)되어 있다는 점입니다. 이는 전담 인력이 없는 소규모 사이트에서 더 큰 문제가 되는데, 이러한 워크플로우를 처리할 때 통지가 과도하게 발생하거나 메시지가 묻히기 쉽기 때문입니다.

[RGJ (Richard - Communiteq)]

@nathank

이 사용 사례에 PM(개인 메시지) 시스템을 사용하는 것은 상당히 강력하고 유연하며(다른 사용자를 끌어올 수 있음), 그러나 중요한 약점이 있습니다. 바로 포럼 본체와 분리되어 있다는 점입니다.

네, 그것이 제 주요 문제입니다. Private Topics 플러그인은 이상적이지 않으며, 개인 메시지는 토론에 다른 사용자를 초대하는 능력 측면에서 더 많은 유연성을 제공합니다.

하지만, 그 모든 해가 지난 지금도 개인 메시지의 오래된 문제들은 여전히 남아 있습니다:

• 전역 태그 필터가 없습니다. 사이드바의 태그 필터는 PM이 아닌 주제만 표시합니다. 다른 링크를 만들 수는 있지만, 항상 메일박스별로만 적용됩니다.
• 개인 메시지에 태그를 붙이는 것은 직관적이지 않고 일관성 없는 구현으로 인해 제한적입니다.
• UX가 여전히 혼란스럽습니다.
  • 메시지가 'Sent(보낸)'에 있는지 'Latest(최신)'에 있는지 이해가 되지 않습니다.
  • 표현이 명확하지 않습니다
  • 여전히 그룹 수신함을 설정하기가 어렵습니다(예: Group inboxes not appearing)
• 검색이 번거롭습니다.
  • Search for messages that involve (both from and to) a user
  • 메시지에 있을 때를 제외하고는 검색 필터를 명시적으로 추가해야 합니다. 그래서 정말로 격리된 것처럼 느껴집니다.