# Use Discourse as a Private Support/Ticket System
**URL:** https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268
**Category:** Administrators
**Tags:** how-to
**Created:** [17.Октябрь.2017 12:35:41 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268 "2017-10-17T12:35:41Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [17.Октябрь.2017 12:35:42 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/1 "2017-10-17T12:35:42Z")
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](https://meta.discourse.org/t/start-a-new-topic-via-email-e-mail/62977)
- [Discourse as a private email support portal](https://meta.discourse.org/t/discourse-as-a-private-email-support-portal/34444)
- [Set up reply by email with POP3 polling](https://meta.discourse.org/t/set-up-reply-via-email-support-e-mail/14003)
- [Private Topics - are they supported?](https://meta.discourse.org/t/private-topics-are-they-supported/47043)
- [Using discourse as a community ticket system](https://meta.discourse.org/t/using-discourse-as-a-community-ticket-system/20607)
- [How to optimize issue/support ticket like workflow?](https://meta.discourse.org/t/how-to-optimize-issue-support-ticket-like-workflow/67820)
- [Can incoming Discourse email support replace old ticket portals?](https://meta.discourse.org/t/can-incoming-discourse-email-support-replace-old-ticket-portals/43522)
- [Create/See and Create Permissions (again)](https://meta.discourse.org/t/create-see-and-create-permissions-again/33150)
## 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](https://meta.discourse.org/t/start-a-new-topic-via-email-e-mail/62977).
## 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.
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.
- 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.
- Set up suspected SPAM email subjects in `Settings|Email|ignore by title`. This prevents emails with suspicious subjects from creating topics.
### 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.
- 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 `Group`s 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`
- 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.
---
### Author:  [@Walker\_Blackwell](https://meta.discourse.org/u/Walker_Blackwell)
#### Post date: [26.Март.2019 18:24:55 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/2 "2019-03-26T18:24:55Z")
> [@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](mailto:help@test.com) to [help@myforum.test.com](mailto: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](mailto: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](mailto: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?
---
### Author:  [@Dannii](https://meta.discourse.org/u/Dannii)
#### Post date: [27.Март.2019 00:15:13 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/3 "2019-03-27T00:15:13Z")
[I just had this same problem](https://meta.discourse.org/t/private-support-categories-staged-users-can-email-in-but-not-registered-users/112594). 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](https://meta.discourse.org/t/start-a-new-topic-via-email-e-mail/62977). I’ll edit this howto to warn against what we’ve both tried.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [27.Март.2019 00:57:10 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/4 "2019-03-27T00:57:10Z")
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.
---
### Author:  [@Dannii](https://meta.discourse.org/u/Dannii)
#### Post date: [27.Март.2019 01:01:47 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/5 "2019-03-27T01:01:47Z")
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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [27.Март.2019 01:29:20 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/6 "2019-03-27T01:29:20Z")
> [@Dannii](#):
>
> you shouldn’t use a category to receive emails unless the whole forum is private
I think that’s a fine clarification.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [29.Март.2019 10:20:40 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/7 "2019-03-29T10:20:40Z")
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).
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [29.Март.2019 10:29:09 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/8 "2019-03-29T10:29:09Z")
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)](https://meta.discourse.org/t/create-see-and-create-permissions-again/33150):
>
> Continuing the discussion from ["Create" Permission](https://meta.discourse.org/t/create-permission/31679/4): Now that the “whisper” functionality ([https://i.imgur.com/orfu6df.png](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.
---
### Author:  [@Walker\_Blackwell](https://meta.discourse.org/u/Walker_Blackwell)
#### Post date: [29.Март.2019 13:30:49 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/9 "2019-03-29T13:30:49Z")
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](mailto: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
---
### Author:  [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [04.Май.2025 11:37:42 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/10 "2025-05-04T11:37:42Z")
Существует ли статья, столь же хорошо написанная, как эта, для тех, кто хочет использовать Discourse одновременно и как стандартную онлайн-сообщество, и как систему тикетов?
Такая, где _ **абсолютно** _ неизбежно будет пересечение между пользователями тикетов поддержки и участниками форума сообщества?
Возможно ли это вообще без целой телеги оговорок?
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [04.Май.2025 12:07:11 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/11 "2025-05-04T12:07:11Z")
В качестве варианта для такого рода сценариев (и многих других) я написал следующий плагин:
> [@Discourse Workflow](https://meta.discourse.org/t/discourse-workflow/347110):
>
> information_sourceSummary A topic-based workflow system for Discourse with configurable steps, actions, workflow list filters, and Kanban viewhammer_and_wrench[Repository Link](https://github.com/merefield/discourse-workflow)[https://github.com/merefield/discourse-workflow](https://github.com/merefield/discourse-workflow)open_bookInstall Guide [How to install plugins in Discourse](https://meta.discourse.org/t/install-plugins-in-discourse/19157) Enjoying this plugin? Please star it on [GitHub](https://github.com/merefield/discourse-workflow)! pray
Его можно настроить в категории (и её подкатегориях) и установить права доступа таким образом, чтобы скрыть её от основного сообщества.
---
### Author:  [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [05.Май.2025 00:05:24 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/12 "2025-05-05T00:05:24Z")
Спасибо за информацию. Знаете ли вы статью «Как сделать», которая объединяет эту статью с вашим плагином, чтобы такие новички, как я, могли быстро всё настроить?
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [05.Май.2025 07:29:33 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/13 "2025-05-05T07:29:33Z")
Другой вариант — это хорошо зарекомендовавший себя плагин от команды [Communiteq](https://www.communiteq.com/):
> [@Private Topics Plugin](https://meta.discourse.org/t/private-topics-plugin/268646):
>
> information_sourceSummary Private Topics Enables private topics in a regular categoryhammer_and_wrenchRepository Link [GitHub - communiteq/discourse-private-topics](https://github.com/communiteq/discourse-private-topics)open_bookInstall Guide [How to install plugins in Discourse](https://meta.discourse.org/t/install-plugins-in-discourse/19157)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 providin…
Это изящно решает описанную выше проблему.
---
### Author:  [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [05.Май.2025 15:31:34 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/14 "2025-05-05T15:31:34Z")
Понятно, и это будет работать в сочетании с поэтапным добавлением пользователей, которые в основном будут создавать «тикеты» в системе, как описано в основной части этого поста?
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [05.Май.2025 15:45:07 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/15 "2025-05-05T15:45:07Z")
Я также хочу отметить, что в Discourse мы используем нашу мета-сообщество именно таким образом.
Когда клиенты пишут нам на почту, вместо того чтобы сообщение попадало в категорию, как описано здесь\[1\], оно создаёт личное сообщение в групповом почтовом ящике, который мы используем как систему учёта заявок. Со временем мы добавили в представление почтового ящика некоторые лёгкие дополнения для удобства, но в основном пользуемся встроенными функциями.
Ключевые элементы нашего рабочего процесса: 1) использование группового почтового ящика, где любой член команды поддержки может ответить; 2) архивация личных сообщений после того, как мы обработали последнее сообщение от клиента.
Когда клиент отвечает, архивированное личное сообщение автоматически возвращается в почтовый ящик, чтобы вся команда снова увидела его.
Команда также может использовать функцию «шёпот» в этих личных сообщениях для совместной работы, а недавно мы начали экспериментировать с «шёпотами» на базе ИИ, когда некоторые результаты предварительного исследования сразу же передаются команде.
* * *
1. Мы также используем приватные категории в определённых случаях, но сейчас это скорее исключение, чем правило — для нас нормой стал рабочий процесс с групповым почтовым ящиком.
---
### Author:  [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [07.Май.2025 02:02:31 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/16 "2025-05-07T02:02:31Z")
> [@schungx](#):
>
> _ПЕРЕСЫЛАТЬ_ все письма с этих конкретных учётных записей на _ГЛАВНУЮ_ учётную запись. Например, необходимо настроить автоматическую пересылку всех писем, полученных по адресу `wonderful_product@support.example.com`, на `master@support.example.com`.
Для тех из нас, кто платит за каждую учётную запись, не могли бы вы создать одну главную учётную запись поддержки и просто добавить алиасы отдельных адресов на неё?
В настоящее время в моей основной учётной записи, насколько я помню, настроено 12 алиасов, некоторые из которых даже относятся к другим доменным именам. Письма, отправленные на любой из этих адресов, приходят в мою основную учётную запись.
Подойдёт ли такой вариант для наших целей?
---
### Author:  [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [09.Май.2025 18:03:39 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/17 "2025-05-09T18:03:39Z")
> [@Walker\_Blackwell](#):
>
> Проблема возникает после того, как я пригласил пользователя стать участником форума. Когда они перестают быть анонимными или временными, они внезапно не могут отправить запрос в поддержку на [help@test.com](mailto:help@test.com). Письмо отклоняется, потому что категория ограничена только для администраторов (для просмотра/ответа/публикации) и для анонимных/временных пользователей (уровень 0) (только для публикации).
>
> Неужели нет способа разрешить пользователям уровня 1, 2 или 3 ПУБЛИКОВАТЬ/ОТПРАВЛЯТЬ письма в категорию, не давая им при этом доступа к просмотру самой категории и всех остальных тем? По крайней мере, я не вижу, как это исправить.
Я знаю, что это очень старый вопрос, но я не заметил, чтобы кто-то другой на него ответил, и мне кажется, что у меня есть решение. По крайней мере, у меня это работает. Я не знаю, есть ли какие-либо непредвиденные последствия от этого, так как я только начинаю, но вот как это сделать.
Мне понравилась идея категорий вместо групп, поэтому я следовал этому руководству по настройке, но также хотел иметь открытый форум и столкнулся с той же проблемой, описанной выше.
Если вы выполните поиск по запросу `email settings in` в админ-панели, вы найдете страницу ниже. На ней показано, что для создания постов через электронную почту пользователям требуется уровень доверия 2.
Временные пользователи обходят это требование, но как только они становятся полноценными пользователями, они все еще имеют уровень доверия 0, и работа с электронной почтой ломается. Так что просто уберите TL2 и добавьте TL0 — и вы в порядке.
Я сделал это вместе с использованием **плагина Private Topics** , ссылка на который приведена выше, чтобы пользователи могли запрашивать поддержку прямо на сайте, и я почти закончил.
Мне осталось только аккуратно интегрировать теги приоритета и статуса, и, думаю, мы будем готовы.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [09.Май.2025 22:08:19 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/18 "2025-05-09T22:08:19Z")
> [@Walker\_Blackwell](#):
>
> Проблема возникает после того, как я пригласил пользователя стать участником форума. Когда они являются кем-то, КРОМЕ анонимных или временных пользователей, они внезапно не могут отправить письмо с запросом в службу поддержки […] Письмо отклоняется, потому что категория ограничена только для администраторов (для просмотра/ответа/публикации) И для анонимных/временных […] пользователей (только для публикации)
> [@tknospdr](#):
>
> Я сделал это, а также использовал плагин **Private Topics Plugin** , ссылка на который приведена выше
Да, это _именно_ то, для чего был создан этот плагин! 👍
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [11.Май.2025 07:55:38 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/19 "2025-05-11T07:55:38Z")
Плагин «Частные темы» отлично подходит для этого, но имеет один существенный недостаток: он позволяет назначать только одного пользователя на тему. Это означает, что вы не можете добавить других пользователей в тему, не раскрывая им все темы из этой категории.
Обходной путь — преобразовать эту тему в личное сообщение (ЛС) или, если уместно, переместить её в более открытое место. Но было бы замечательно иметь возможность указывать других пользователей (и/или группы), которые смогут получить доступ к конкретной теме. Однако, я думаю, это потребует довольно сложного решения.
> [@mcwumbly](#):
>
> Ключевые элементы нашего рабочего процесса: 1) использование группового почтового ящика, где любой сотрудник службы поддержки может ответить; 2) архивирование ЛС после обработки последнего ответа.
Использование системы ЛС для этого сценария очень мощное и гибкое (и позволяет привлекать других пользователей), однако у него есть и существенный недостаток: она изолирована от основного форума. Это становится гораздо более серьёзной проблемой на небольших сайтах без выделенных сотрудников для обработки запросов поддержки, так как это приводит либо к чрезмерному количеству уведомлений, либо к тому, что сообщения теряются.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [11.Май.2025 09:12:10 UTC](https://meta.discourse.org/t/use-discourse-as-a-private-support-ticket-system/72268/20 "2025-05-11T09:12:10Z")
> [@nathank](#):
>
> Использование системы личных сообщений (ЛС) для этого случая очень мощное и гибкое (и позволяет привлекать других пользователей); однако у него есть существенный недостаток: оно изолировано от основного Форума.
Да, это действительно моя главная проблема. Плагин «Частные темы» далёк от идеала, а личные сообщения предлагают большую гибкость в возможности приглашать других участников к обсуждению.
Но после всех этих лет давние проблемы с личными сообщениями всё ещё актуальны:
- Отсутствует глобальный фильтр по тегам. [Фильтр по тегам в боковой панели показывает только не-ЛС темы](https://meta.discourse.org/t/displaying-pms-in-tag-lists/213777). Можно создать другую ссылку, но она всегда будет привязана к конкретному почтовому ящику.
- Разметка личных сообщений тегом работает неинтуитивно и ограничена из-за [непоследовательной реализации](https://meta.discourse.org/t/inconsistent-code-requirements-for-pm-tagging/362931).
- UX продолжает вводить в заблуждение:
- Я не понимаю, когда сообщение находится в разделе «Отправленные», а когда — в разделе «Последние».
- [Формулировки неясны](https://meta.discourse.org/t/you-dont-have-any-messages/365212).
- Мне всё ещё сложно настроить групповые почтовые ящики (например, [Group inboxes not appearing](https://meta.discourse.org/t/group-inboxes-not-appearing/305508)).
- Поиск неудобен:
- [Search for messages that involve (both from and to) a user](https://meta.discourse.org/t/search-for-messages-that-involve-both-from-and-to-a-user/349458)
- Необходимо явно добавлять [фильтр поиска](https://meta.discourse.org/t/how-to-search-filter-pms-based-on-tags/263316/2?u=rgj), за исключением случаев, когда вы находитесь в разделе сообщений, что создаёт ощущение полной изоляции.