We would like to set it up so Discourse can act as a private email support portal for a team. In this mode a single email address will be mapped to a category, all incoming mail will create new messages in that category that can be viewed by all the users with permission on the category. Users will be automatically provisioned as emails come in.
Advantages over central email box
Historically we have used a central email box for our team “support” this has proven to have quite a few drawbacks.
- No per-user read / unread tracking, we keep needing to “mark stuff as unread” to avoid confusing the main owner.
- Very poor historic record, no ability to search cleanly.
- Very hard to have in context out-of-band discussion about a support issue. (whisper feature)
- Long email threads are a huge pain to cope with
To solve this we would like to allow messages to have a category. As it stands categories already can have an incoming email address.
The big change is allowing “messages” to have categories with all the fallout that ensues.
The first step of the process is going to be accepting incoming mail. To accept incoming mail from an unknown user we will need to create an account.
One huge area of confusion we have seen with mailing list migrations is account creation. If we automatically “create” accounts for users, a large amount of confusion ensues
“Why can I not create an account on the site”.
Additionally, if we automatically create accounts there is are quite a few side effects:
- We start sending digests to the users
- User becomes “part” of the site unwittingly. They can be mentioned, searched and so on.
For support this is highly undesirable.
Instead I would like to amend it so incoming mail just create an “inactive staged account”, if later the user attempts to register it we should allow them to do so with minimal confusion, including allowing the user to pick a username and name. For all intents and purposes this account will not exist, except when posting on very specific messages.
As it stands if you try to register with an “inactive” account we will prompt you with confusing warnings. We will add another flag to users to explain this “inactive” account was in a “staged” state.
If the user is already in the system with an active account this is a non-problem.
Topic Allowed Users
Currently, to keep track of the users that have access to a message we use the table “topic_allowed_users” this maps users to topics. Each topic may have 0 or more “topic allowed users”
Message permission changes
Allow messages to have a category
Messages in a category all follow the same permissions as assigned to the category in addition to explicit permissions on the topic. EG: “support staff EMEA” may have permission on “EMEA support”. After an email is processed “topic allowed users” will include ONLY the author. “EMEA support” will be able to view the message because they have permission on the category.
Messages will have to start showing up in topic lists (except for messages with no category)
If a response is made to a message the responder should automatically be added to “topic allowed users”, this should have always been the case.
Staged inactive accounts need to get email notifications for any replies to messages, but nothing else
If a user has full permissions on a “message” type group, they can add and remove users from “topic allowed users”
Onboarding staged accounts
Emails we send usually include various links to Discourse, if clicked by “staged accounts” they should first funnel through an onboarding process, where a user is presented with the sign up form.
Often (like in our case) there is already an incoming mail box for support, we would like to make the transition to Discourse as smooth as possible. To do so it is best to allow this system to operate side-by-side during the migration.
As it stands we only allow one set of credentials for “email polling”, this leaves 2 options:
- Allow user to specify email credentials per category.
- Allow “polled” mailbox to accept automatically forwarded emails from another mailbox.
Initial implementation will focus on (2), it is fairly trivial to setup email forwarding rules, additionally this will play much nicer with the hosted email-in solution we are going to be offering all our customers.
At the moment the only type of notification a message can generate is a “green bubble” notification. This is the strongest type of notification in the system. The green bubble will not go away until you visit a message.
This behavior is highly undesirable for a support team, only the assigned “supporter” should be disrupted in this way.
Instead we will allow notifications on messages to be standard blue notification IF the user is not in the “topic allowed user” list (and instead has implicit permissions due to group permissions)
To reduce friction, always add people who reply to messages to “topic allowed users” this should be done globally.
What about latest and topic lists
We need to decide if we allow messages in categories to be mixed up in the “latest” category list.
Since we already have a setting on categories that allows you to exclude a category from latest we will simply respect it and allow the forum owner decide if they want to “mingle” data or not.
User page changes
No changes really need to be made on the user page, we should only display messages where a user is in “topic allowed users” in the sections there. To see “support” issues “staff” are managing they will need to visit the “support” category.
Creating support topics outside of email
Support categories will be suppressed from the category selector, if we leave it there it can quickly cause confusion and force us to implement messy migration of messages to non message categories etc.
Only way to create “support” style topics from the UI will be a dedicated link on the “support” category. (this will have a nice URL and be easily linkable - with anonymous onboarding if needed)
Message that have a category set should show up in search IF the user has permissions on the category and category is not suppressed from latest. Otherwise they will need to explicitly search in the category to see the messages.
Suggested topics changes for Messages
As it stands suggested topics are absent from messages. Instead we should amend it for messages containing categories.
- Always show a list of all other messages by the OP (priority 1) - this provides context for support.
- Try to show new/unread in the same category for users with permissions (priority 2)
- No random
- Initially only apply this rule for messages with categories
In the context of a message in a support category, whispers should be visible and usable by all users who have access to the support category. This means that in some cases non-moderators may have access to the whisper feature.
For example: a company of 1000 people using Discourse with a regional support group handling a regional support email.
I realize the scope here is quite huge, any feedback welcome, this is a planned feature for our upcoming release I will be working on.