将Discourse用作私人支持/工单系统

社区维基 管理员
1

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

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.

43 个赞
2

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.

30%20PM

How to fix?

3

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.

4 个赞
4

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.

5

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.

2 个赞
6

I think that’s a fine clarification.

1 个赞
7

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).

8

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:

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.

9

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

4 个赞
10

是否有一篇写得像这篇一样好的文章，供那些希望将 Discourse 用作标准在线社区和工单系统的人使用？
有没有一个帮助工单用户和社区论坛用户之间绝对会有重叠的地方？
这是否有可能实现，而无需一大堆限制条件？

2 个赞
11

作为这种用例（以及更多用例）的一个选项，我编写了以下插件：

您可以在类别（及其子类别）中设置它，并以某种方式设置权限，以将其排除在主社区的视野之外。

1 个赞
12

我感谢你提供的信息。您是否知道有关将本文与您的插件合并的“操作方法”文章，以便像我这样的新手能够开始使用它？

13

另一个选择是来自 Communiteq 团队的这个成熟的插件：

这很好地解决了上述问题。

1 个赞
14

我明白了，这是否会与该帖子正文中概述的、将主要在系统中创建“工单”的暂存用户协同工作？

15

我们在这里使用 Discourse 来分享我们的元社区。

当客户给我们发邮件时，它不会像这里[^1]所描述的那样进入一个分类，而是会在这里创建一个私信（PM），我们将其用作我们的票务系统。随着时间的推移，我们为收件箱视图添加了一些轻量级的装饰，但主要还是在使用内置功能。

我们工作流程的关键部分是 1) 使用一个群组收件箱，支持团队中的任何人都可以回复 2) 在处理了最新的回复后存档私信（PM）。

当客户回复时，存档的私信（PM）会自动带回收件箱，以便整个团队再次看到它。

团队还可以通过私信（PM）进行悄悄话交流以进行协作，我们最近也开始尝试使用 AI 悄悄话，其中一些初步研究会提前与团队共享。

[^1]：在某些情况下，我们也使用私有分类，但这现在已成为例外而非规则——群组收件箱工作流程已成为我们的常态。

3 个赞
16

对于我们这些必须按电子邮件帐户付费的人来说，您能否创建一个单一的主支持帐户，并在该帐户上为individual地址创建别名？

现在我的主帐户上有我认为的12个别名，有些甚至是不同的域名。发送到任何这些地址的电子邮件都会转到我的实际帐户。

这能为此目的工作吗？

17

我知道这是一个很老的问题了，但我没有看到其他人回答过，我认为我找到了解决方案。至少它对我来说是有效的。我不知道这样做是否会有任何意想不到的后果，因为我才刚刚开始，但这是我的方法。

我喜欢类别而不是用户组的想法，所以我遵循了这个设置指南，但我也想要一个开放的论坛，并且遇到了上面提到的同样问题。

如果您在管理员中搜索 email settings in，您会找到下面的页面。它显示用户需要信任级别 2 才能通过电子邮件创建帖子。

暂存用户可以绕过该要求，但一旦他们成为正式用户，他们仍然是信任级别 0，并且电子邮件会中断。所以只需删除 TL2 并添加 TL0，您就搞定了。

我这样做了，并使用了上面链接的 Private Topics Plugin，以便用户也可以直接在网站上请求支持，而且我几乎完成了。

我只需要整齐地集成优先级和状态标签，我认为我们就准备好了。

The image shows a settings page for configuring email capabilties, with options like "Show signup form email instructions" and "Email allowed groups" for management of new topic postings via email. (Captioned by AI)
The image shows a settings page for configuring email capabilties, with options like "Show signup form email instructions" and "Email allowed groups" for management of new topic postings via email. (Captioned by AI)1968×766 92.2 KB

2 个赞
18

是的，这正是该插件的用途！:+1:

2 个赞
19

Private Topics 插件在这方面非常出色，但有一个重要的弱点：它每个主题只能允许一个用户。这意味着您无法将其他用户添加到主题中，而不会向他们显示该类别中的所有主题。

解决方法是将该主题转换为 PM，或者在适当时将其移动到更开放的位置。但如果能够指定其他用户（和/或组）来访问该特定主题，那就太好了。但我认为这需要一个相当复杂的解决方案。

使用 PM 系统处理此用例非常强大且灵活（并且允许引入其他用户）；但是，它也有一个重要的弱点：它与论坛本身是隔离的。这在没有专门人员处理支持工作流程的小型网站上是一个更大的问题，因为它往往会过度通知或被埋没。

1 个赞
20

是的，这确实是我的主要问题。私有主题插件远非理想，并且就邀请其他用户参与讨论的能力而言，个人消息提供了更大的灵活性。

但是，经过这么多年，个人消息中长期存在的问题仍然存在：

4 个赞