Offering "private support" as part of a public support community

[RGJ (Richard - Communiteq)]

I have been thinking about this for a while and I decided to throw my ideas in the group and ask you all what you think.

In the past months I have talked to a quite lot of people that are trying to set up direct client support - where a support team resolves (confidential) client specific issues - as an addition to their existing (public) community support forum.
Most of those solutions involve the ‘assign’, ‘solved’ and ‘ticket’ plugins and then there are multiple approaches (but it seems there is no golden bullet and that is why I am making this topic).

Solution #1: Create separate categories / groups for each client

This only works when you have a relatively small amount of clients, not when you have hundreds.

Solution #2: The one described by schungx “How to Use Discourse as a Private Support/Ticket System”

The main party pooper here is: “(…) 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.”

But this topic does address one of the main issues: “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.” I will get back to this below.

Solution #3: Group inboxes.

Sams original idea “Discourse as a private email support portal” which became group inboxes. You set up a group inbox, assign it to your support team, and everyone can send or email messages to the inbox.
This is now the go-to solution and it works.

However, I don’t like it a lot.

In my opinion (!), there are a number of drawbacks to this approach, and the main three are:

• Messages sent to the Support group are hard to find (actually, IMHO all messages are hard to find if you don’t have a notification to click on) and although support staff has a good overview, a user does not. Where the staff users working on the tickets see a separate group inbox, users that have created the tickets can only find them between their ‘regular’ PM’s.
• Lack of tagging support in PM’s: Only staff can tag PM’s and users cannot see or filter on tags.
• There is no “place” where one can go and send a message to. The possibility to message the Support team must explicitly be advertised somewhere (and I find it hard to find a logical place for this, most of the time it ends up in some kind of banner).

All in all, for me it feels a bit ‘bolted on’ and a compromise between category topics and PM’s.

#4 Private topics

This idea has been pitched a number of times (also here here and here) , and I already mentioned the “create” and “create/reply” permissions above.

What if there was some kind of ‘drop box’ category where people can start a topic and interact with support staff (basically: a group), where only they and members of that group can see the topic?

That would be a golden bullet for this use case. We would have a clearly defined “support” category where every user can see their (and only their) support tickets. Everything is in a single place and you can use tagging and everything.

But both @codinghorror and @sam have told us many times that topic specific permissions are not going to happen (which I totally understand, since it adds a lot of complexity).

---

I see two ways forward: use the #3 group inboxes and hope those drawbacks are resolved, or give the #4 private topic idea another shot.

In the meanwhile a few plugins that mess with implement per-topic permissions have come up, like Restricted Replies - only allow certain groups to reply in a category and Discourse Private Replies which makes replies invisible to everyone except the topic starter (and staff) … and it seems doable… so I have been considering giving this another shot in a plugin.

But.

Before I proceed with this I would be interested to hear

• if other people share my opinion with respect to the group inboxes, since I am aware these perceived disadvantages could be very subjective.
• any (!!) feedback on the private topics plugin idea

[Heliosurge (Dan DeMontmorency)]

This is Indeed a very good topic to discuss.

The private replies might be abled to be forked perhaps to come up with something along your idea. But will require someone whom knows what there doing or discussing maybe with the plugin author if maybe a sponsored plugin fork. With sponsoring this would be great to explore a form of crowd funding concept.

Discourse Private Replies

Github: GitHub - communiteq/discourse-private-replies This plugin hides topic replies for everyone but the topic starter and the post author. Use cases This can be used for for instance homework assignments where the teacher opens a topic and posts an assignment, and all students make a post with their answers. When everyone has submitted their work, the teacher can open up the answers so the students will be able to discuss them. A second use case can be an auction where something is offered…

---

The group mailbox is a great idea, however imho the PM system needs to have an easy to use Search option, or Group BookMarks with using a Folder option. Ie Client A Oct 2020 requests.

[Simon_Manning]

@RGJ

But both @codinghorror and @sam have told us many times that topic specific permissions are not going to happen (which I totally understand, since it adds a lot of complexity).

Without knowing the original context, topic specific permissions seems like a much broader (and as you said, much more complex) prospect than what would be required to make #4 work.

The way I would envisage this working is by extending the category permissions to include See Own. Similar to how the permissions are now, one of “See” or “See Own” must be allowed for a group that has been added.

As allowing Create automatically allows Reply, See Now would automatically allow Create - a category where you can only see your own topics would be kind of pointless if you can’t create topics.

I think this would “only” need two additional changes in permissions territory. When the groups the current user belongs to only affords See Own permission:

1. The topic listing should filter to topics created by the current user
2. Access to topics should be denied unless the topic was created by the current user

I suspect in reality there is additional complexity dealing with things like the Latest topics list but probably (maybe…) not an enormous amount of extra work.

@RGJ

• if other people share my opinion with respect to the group inboxes, since I am aware these perceived disadvantages could be very subjective.

We don’t currently do private support in Discourse so I don’t have first-hand experience but I think my own perceptions are in line with yours.

Discoverability is important, both in finding where to ask for support and in reviewing current and past support queries, which looks to be potentially challenging with the group PMs approach.

[RGJ (Richard - Communiteq)]

@Heliosurge

The private replies might be abled to be forked perhaps to come up with something along your idea. But will require someone whom knows what there doing or discussing maybe with the plugin author if maybe a sponsored plugin fork. With sponsoring this would be great to explore a form of crowd funding concept.

Thank you for your feedback! I happen to be the author of that specific plugin, and we (Communiteq) are prepared to invest in this if we get the feeling that this is the right direction. So those things will not be a problem.

@Simon_Manning

I think this would “only” need two additional changes in permissions territory. When the groups the current user belongs to only affords See Own permission:

• The topic listing should filter to topics created by the current user
• Access to topics should be denied unless the topic was created by the current user

Yes, that sounds right.

I’m still struggling a bit with how this would exactly be structured though, since See Own implies Create, Create implies Reply, and Reply implies See.
But we don’t want to have See Own imply See.

[Heliosurge (Dan DeMontmorency)]

Yeah I see that. Should have paid better attention.

[Simon_Manning]

@RGJ

I’m still struggling a bit with how this would exactly be structured though, since See Own implies Create , Create implies Reply , and Reply implies See .
But we don’t want to have See Own imply See .

Yeah, this appears to be trickier than I thought. It looks like Reply doesn’t actually imply See but a group being added to category permissions at all does.

The permissions are an enumeration where a group has exactly one of readonly, create_post or full. Finding out if a user can reply/create in a given category boils down to getting a list of all the categories where the user is part of a group that has (create_post or full) to reply or (full) to create a topic and checking if the relevant category is amongst that list.

Creating topics is easy, having an extra value in the enumeration like full_own just works with it added to the TOPIC_CREATION_PERMISSIONS constant in category.rb. If the user has either full or full_own for the relevant category, they can create a topic.

Replies are more complicated but I think it would be appropriate to add an additional scope which returns all the categories where the user has full_own. Something like:

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

Then in post_guardian.rb, can_create_post? needs an extra condition like:

    (!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)
    )

However, seeing only one’s own topics and guaranteeing that is true across the relevant category page, latest, search and anywhere else looks much more challenging. I haven’t figured that out.

[tobiaseigen]

I think the lowest hanging fruit here is door number 3, improving group inboxes so they work well for providing support to people who log in, not just to people who email for support.

@RGJ

• Messages sent to the Support group are hard to find (actually, IMHO all messages are hard to find if you don’t have a notification to click on) and although support staff has a good overview, a user does not. Where the staff users working on the tickets see a separate group inbox, users that have created the tickets can only find them between their ‘regular’ PM’s.
• Lack of tagging support in PM’s: Only staff can tag PM’s and users cannot see or filter on tags.
• There is no “place” where one can go and send a message to. The possibility to message the Support team must explicitly be advertised somewhere (and I find it hard to find a logical place for this, most of the time it ends up in some kind of banner).

Your main complaints about group inboxes seem to be about the lack of functionality on the user end, which is legit if your users are logging in to pursue tickets and are also using PMs to talk to other people on the site. I have not encountered this very much so far in our use of group inboxes to provide support here on meta. Most of the people we provide support to via the group inboxes don’t ever come to log in - they mostly use their own email and so can use their email to organize and archive their correspondence with us as they see fit.

I do have a few users I communicate with via @support-teams here on meta, so will ask them how it works for them and if they have any suggestions. I’ll also do some more testing on my own to see how this actually works now. It seems to me the request is:

• allow non-staff users to see message tags (currently only staff see tags. maybe we can use tag groups for this, to provide some tags that non-staff can see in messages? )
• provide a link to group inboxes on the messages menu for users when they are messaging groups, to see own messages with groups (this works already for staff, not sure how it works for non-staff. there are issues here with inbox vs archive, which are not individually controlled on a per user basis)
• provide a link to start a new message to a group (I think this exists on the group page if messaging the group is allowed)

The ability to start a new message to a group is something even I have noticed, as a member of the @support-teams group to provide Discourse for Teams email support. If I want to start a new message from the support team, I have to include both the support team and the email address of the person I want to write to. This is a bit clunky.

Also, the way we use group inboxes, we do not usually close messages as we would topics when they are resolved. We just archive them. This allows us to get them out of sight for ourselves when they are resolved, but also to allow the customer to follow up by email and move the message back to the inbox.

[Simon_Manning]

@tobiaseigen

Also, the way we use group inboxes, we do not usually close messages as we would topics when they are resolved. We just archive them. This allows us to get them out of sight for ourselves when they are resolved, but also to allow the customer to follow up by email and move the message back to the inbox.

This is quite an interesting point that I hadn’t really considered. With email support it’s very common that customers will find old emails and reply to them rather than sending a new email. If a topic is closed, that will probably be confusing at best when they find their email rejected.

Behind door number 4, in whatever way that could come to pass, it would probably be difficult on the staff side to identify topics that haven’t been dealt with if they can’t be closed, especially with greater numbers of support staff. The Solved plugin won’t really help here because the customer could reply to an old topic and the various support staff won’t know if it needs attention or if another member of staff has solved it already.

[RGJ (Richard - Communiteq)]

I’m not sure if messing with the full, create_post and readonly is the right way to go, since full and create_post do imply “see all” in quite some places. It won’t be easy to create a maintainable plugin that way. Additionally, I think it would be not very intuitive.

Also, it would be cool if the topic author would be able to add extra people (for instance a colleague) to the topic, for instance by mentioning them, and in that case this mechanism won’t suffice.

Right now my idea is to leave the permissions intact and add a section below the security groups:

---

Enable private topics in this category
Allow the following groups to see all topics [x support staff] [x sales support]

---

@Simon_Manning

However, seeing only one’s own topics and guaranteeing that is true across the relevant category page, latest, search and anywhere else looks much more challenging. I haven’t figured that out.

I did a similar thing in the private replies plugin, but then for posts in a topic instead of topics in a category.
I think I’ll get pretty far with some patches in TopicGuardian.

@tobiaseigen

think the lowest hanging fruit here is door number 3, improving group inboxes so they work well for providing support to people who log in, not just to people who email for support.

Yes, that could be very low hanging fruit. Your summary of my request is accurate, and I found two more things that would bring messages more in par with topics.

• When I search the forum I have to explicitly add in:private to my search query to search my messages. Sometimes I really don’t remember if something was a (more or less public) topic or a PM to a group. Why not include them by default?

• Additionally, I think it would be nice if there was a simple link to the messages in the right tab of the hamburger menu. Yes, there is the envelope icon, but it has a list of messages, and not a link to the messages screen at /my/messages. That screen feels tucked away.

The items in the drop down are partly the same as the tabs in the next screen, except for Messages and Badges. So when I need to go to my messages, I always click Summary and then Messages.

Compare the items in the drop down

with the tabs in the profile screen

There’s Summary, Activity, Invites and Preferences in both, but Drafts in one and Notifications, Messages and Badges in the other. So “Messages” feels very hidden for me (that goes for Notifications and Badges as well but I don’t use them that often).

[tobiaseigen]

@RGJ

• When I search the forum I have to explicitly add in:private to my search query to search my messages. Sometimes I really don’t remember if something was a (more or less public) topic or a PM to a group. Why not include them by default?

Good point. I’m not sure what the thinking is behind this barrier. I’ve also noticed that when you are in your messages, it does add in:personal by default which is good! But it does not add e.g. in:support-teams to search just the group inbox for messages which I think would be a good idea. The advanced search also has no easy way to filter by group inbox that I am aware of. (cc @pmusaraj)

@RGJ

Additionally, I think it would be nice if there was a simple link to the messages in the right tab of the hamburger menu. Yes, there is the envelope icon, but it has a list of messages, and not a link to the messages screen at /my/messages. That screen feels tucked away.

This is a good idea but I think there is a problem of real estate on that pulldown - you don’t want to have more than 7 items on that list. Also, for most communities I don’t believe we actually want to promote messaging… we want people to be talking in public! For those who are talking in messages, the notifications pulldown and email notifications etc provides plenty of just in time access to the messages needing attention.

That said, we are actively working on improvements to the menu system (keyword: sideburger) so will take this issue into account. The sidebar in Discourse for Teams already provides ready access to group inboxes and watched tags, which we can bring to core discourse along with the sideburger project.

Here’s how it looks now when I am in the Kabissa group inbox, on m my Discourse for Teams site:

[Simon_Manning]

@tobiaseigen

• provide a link to start a new message to a group (I think this exists on the group page if messaging the group is allowed)

I wonder about designating groups as support groups and having a hamburger menu entry based on this, with these states:

• 0 groups designated for support, no menu entry
• 1 group designated, a “Message Support” entry which starts a message to the group
• >1 groups designated, a “Support” entry which links to a page much like Groups, displaying all the designated groups with Message buttons

Perhaps the extra menu entry and page is overkill. An additional generated section on the About page?

@RGJ

• Additionally, I think it would be nice if there was a simple link to the messages in the right tab of the hamburger menu. Yes, there is the envelope icon, but it has a list of messages, and not a link to the messages screen at /my/messages. That screen feels tucked away.

It’s not totally obvious but this is there on the messages tab, the downward arrow at the bottom of the list of messages will take you to the /my/messages screen. No fewer clicks than Summary, then Messages but one fewer page load.

@tobiaseigen

Here’s how it looks now when I am in the Kabissa group inbox, on m my Discourse for Teams site:

If I were a user sending a message to Kabissa, would that topic be primarily associated with the group in some way, or would the topic have nothing more than my user and the Kabissa group being allowed access?

If it does get primarily associated with the group, would it be feasible to show that Kabissa inbox on my messages page in the same way, albeit obviously only including messages that I have access to.

[tobiaseigen]

When I tested this here on meta, by creating a tl0 user, I was able to navigate to the support-teams group page and select the Message button to send the group a message. Once I posted the message, it landed in my sent messages folder. So that is working though maybe a bit too buried for some cases. You can always add links to the hamburger menu as you see fit to suit the purposes of your site, or in a banner on your homepage etc. So I don’t see that there is much more that needs to be done here?

The Kabissa inbox in that screenshot is just shown to people in the Kabissa group. People messaging Kabissa would see the messages in their own messages.

[jomaxro (Joshua Rosenfeld)]

@RGJ

• When I search the forum I have to explicitly add in:private to my search query to search my messages. Sometimes I really don’t remember if something was a (more or less public) topic or a PM to a group. Why not include them by default?

Do note that in:all exists. That’ll show both public and personal in one search.

If I recall history correctly, the idea was to enforce separation between personal messages and public topics. Minimize any confusion over what is public and what is personal. That said, group inboxes blur that separation quite a bit.

[Simon_Manning]

@tobiaseigen

You can always add links to the hamburger menu as you see fit to suit the purposes of your site, or in a banner on your homepage etc. So I don’t see that there is much more that needs to be done here?

I was thinking along the lines of increasing discoverability of support-specific groups. Adding links to the hamburger menu would certainly suit a community with a single support group (which is actually ideal for my own purposes) but a community with many support groups might benefit from a page or section on the about page generated for specified groups.

In retrospect, this is probably more suited to a plugin if a community needs that.

@tobiaseigen

The Kabissa inbox in that screenshot is just shown to people in the Kabissa group. People messaging Kabissa would see the messages in their own messages.

What I was trying to ask, perhaps poorly, was whether the model currently has enough information to make it possible (in the future) to show users filtered inboxes for groups they interact with but do not belong to. This relates to @RGJ’s concern of messages sent to groups being hard to find.

For example me, as a normal user on your Discourse for Teams site, being able to see a Kabissa inbox in my messages which shows all the messages I’ve sent to the Kabissa group. (Or probably messages I am a participant in.)

My suspicion is that it does not, it probably just has the participants to go on which could be any number of users and groups.

[schungx (Stephen Chung)]

@RGJ

In the past months I have talked to a quite lot of people that are trying to set up direct client support - where a support team resolves (confidential) client specific issues - as an addition to their existing (public) community support forum.

It’s great that this is catching on! That’s because I find that Discourse is one fabulous system for private support tickets and, when it works, it works wonderfully.

I know full well that this is not what Discourse is designed for, and that I’m trying to shoe-horn Discourse into doing something that it is not supposed to do, but between private in-boxes vs. the full glory and features of main topics, I’d choose the latter any day and continue to try shoe-horning…

[codinghorror (Jeff Atwood)]

@schungx

I know full well that this is not what Discourse is designed for, and that I’m trying to shoe-horn Discourse into doing something that it is not supposed to do, but between private in-boxes vs. the full glory and features of main topics, I’d choose the latter any day and continue to try shoe-horning…

This is something we want to support, (figuratively and literally), but we don’t want to be shoehorned into a “support tool” corner. If you have specific feedback on how to make Discourse better in this role, let us know.

We’re always listening

[jrgong]

@RGJ

What if there was some kind of ‘drop box’ category where people can start a topic and interact with support staff (basically: a group), where only they and members of that group can see the topic?

Love the idea! Even from our community we have requests for support tickets separate from their user inbox. This kind of category in which users can only see their own tickets would be super helpful.

[jerry0 (Jerry)]

@codinghorror

This is something we want to support, (figuratively and literally), but we don’t want to be shoehorned into a “support tool” corner. If you have specific feedback on how to make Discourse better in this role, let us know.

Thanks!

We use a PM group for private support - it works well. The main complaint that heavy users of the support system have is an inability to search through their messages.

We have tried to teach them that they must add the code in:personal to the search query in order to search their messages, but it’s not intuitive and, to be frank I haven’t seen a single one of the users actually managing to do this, they just give up and complain that they can’t search their messages.

They don’t even understand what this “suggestion” below the search box is for.

And if they go to advanced search they might be advanced enough to tick the “search messages” radio button but it all starts to look strange when that adds the words in:personal and they give up at that point.

If there was a much more intuitive way to search messages that didn’t involve adding code to the search box, that would be a massive improvement.

If not, just using more intuitive language e.g. the code “in:messages” would be a slight improvement.

[pfaffman (Jay Pfaffman)]

Or maybe just have search include pms by default?

[jerry0 (Jerry)]

Indeed - that would be wonderful!

A setting “Search PMs by default” (which is normally off) would really be ideal.

In that way, any worries about users getting mixed up between search results for normal topics and PM topics (which I don’t have) could be balanced against people not being able to search PM topics at all (which I do have)