Create/See and Create Permissions (again)

Feature
1

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 like this would immensely benefit.

##Create Permission

This permission allows you to post to a category, but not to see un-pinned threads that you weren’t explicitly invited to.

Something like this would be used to ensure confidentiality – only you, specific groups, and the site staff can see what’s happening in your topic.

I could see a use case as a “support forum” where people can post issues and get replies from only verified people.

Now, I know that this can already be achieved by using private messages, but that causes some organizational problems (you might have to do some searching for what you want). Additionally, it causes extra pains of deciding who is invited to the private message.

##Create/See Permission

This has already been discussed, so I’ll keep it short.

Basically, this permission lets everyone create a thread and see all other threads, but not to reply to non-own threads.

It’s main use would be to only allow experienced/trusted/verified/whatever users be able to reply and answer threads. This can be used in all sorts of environments, most particularly as a Q&A system (especially combined with the Solved plugin). Anyone can post a question, but only users who are verified/know what they’re doing can actually answer it.

7 Likes
3

Regarding create, it feels a lot more like an extension of the pm system, what changes would you make to it to have it fit your use case?

5

Think of it like a dedicated folder that holds PMs only for support queries or whatever. It’s advantage over standard PMs is that someone can go right in and see all of their previous support requests, as well as any support requests they’ve been invited to. Additionally, it also removes the clutter of other off-topic PMs in the way.

It’s a dedicated place to go for support that has very high visibility and organization, while still retaining privacy.

6

I do wonder though, instead of framing this as a permission, if it could be framed as “category only includes PMs” or “Category can include PMs”

Allowing PMs to have a category essentially solves this

2 Likes
7

Allowing PMs to have a category would also reduce much of the special casing around the PM code as I recall.

1 Like
8

The reason I personally think it would function better as a permission is because the user isn’t stuck with the burden of deciding who the support topic goes to.

Unless there will be some way to force PMs in a category to go to a certain destination…

9

This also ties into sending PMs to groups which we want to improve / allow at some point.

2 Likes
10

Maybe with better group tagging too (@someRandomGroup no longer expands to all group members)? :wink:

2 Likes
11

Yes exactly that! So maybe we can start by supporting categories on PMs somehow…

1 Like
12

I don’t think PMs should support categories. Categories in Discourse are becoming specialised and specific: They can have special plugins enabled (Solved, Prefilled) and they can have special permissions (“only TL2+ allowed”, “private”).

Should a PM inherit some of the unique properties of its assigned category?

If yes, how.

If no, I guess you’d want to create unique categories specifically intended for PMs then, which means you’re not really using Categories at all, you’re inventing yet another new taxonomy for Discourse.

It seems much more reasonable to support tags instead.

But if you’re going that far, couldn’t you just as well implement the create/create&see (+ other) permissions instead, and re-implement PMs based off of that?

Some other limitations of PMs:

  • You can’t create a topic by e-mail (like you can with ZenDesk et.al.)
  • You can’t assign tags
  • You can’t (easily) move it to a public category (say, it’s a great FAQ item, and the customer gives you permission to share it)
  • I believe it would be much harder for newly appointed Mods to get access to old topics, which can be an invaluable resource.
13

Here’s a random idea:

PMs could be a category. Just one. A special, default one, part of the package like Lounge and Meta.

It could use the same principles as the approach suggested for topic archives:

So when you PM someone, your topic ends up in this special “PM Category” that isn’t visible in the normal drop-downs, not even to Admins. So besides the fact that it’s essentially an unlisted topic shared with whichever participants have been invited, you can tag it, wikify it etc., just like you could with any other topic.

(sorry if this seems off-topic, but I think it’s very much on-topic, since we’re discussing whether OP’s suggestion is better off dismissed in favor of PMs, which I’m arguing is not the right way to go).

14

IMHO this would be a bad thing.
True, it would be hoped that Admins wouldn’t abuse the ability and snoop, but they should be able to check on any message that was reported as being a problem.

15

It was a bit unclear, but I was piggybacking off of the archives suggestion:

a special category that doesn’t show even in staff lists (but retrievable through admin panel somehow)

In other words, I agree; PMs should still be accessible to Admins like they are now, via user profiles, and by invitation/report.

2 Likes
16

Is this “Create only” permission part of any upcoming release.? I saw this mentioned in a blog article (feedback from gaming forums).

17

Nope, not in any release.

If you need private communication targeted at a group of users use the messaging system. Making this more obvious and usable is on the roadmap though.

1 Like
18

Thanks. In that Case, can we disable PMs between users and enable PM between user and admins ?

1 Like
19

PMs cannot be disabled between users and staff. So when you disable PMs you are effectively disabling it only for users.

Let me make sure the copy is clear on this because you bring up a good point. I changed it thusly, adding the bit in bold:

Allow trust level 1 (configurable via min trust level to send messages) users to create messages and reply to messages. Note that staff can always send messages no matter what.

20

Just to be completely sure. Is the reverse also true. Can an user always initiate / create PMs with staff ?

1 Like
21

Nope not if you disable PMs they cannot. Only staff can.

1 Like
22

oh ok. Any chance to implement user initiated staff PMs ? This will help in all communities who disable PMs but still provide a chance to reach the staff through the UI.

1 Like