Give groups Full Names and allow mentions

(Dan Porter) #1

One feature which I miss in Discourse is the ability to mention user groups inline in posts, or when sending a private message to insert the group name rather than typing them in individually.

This feature would be greatly enhanced if groups were more than just their id field, and had a field just like users do for Full Name.

What are your thoughts?

Watch category on bulk invite
Group Tagging System
Inviting all usergroup members
Chat Plugin features
What are Mentions?
(Sam Saffron) #2

Internally we have this functionality, the trouble is

  1. Exposing this in the UI
  2. Adding checks and balances. Clearly we don’t want to allow @joerandom to mention #trust_level_1 group or some other group with 1000 users and generate an email blast.

I am slightly open to having this available as a mod function. But even as a mod function you would need some checks and extra confirmation dialogs.

(Benjamin Kampmann) #3

Hey there,

during hackership we also used discourse a lot and that was one of the annoyances we had: how to mention a full group. Thinking it further I realised that groups can change and that makes mentions of them a weird thing and thought that a more explicit approach might be more useful.

I came up with a system where groups work as aliases for the list of users in the group - which is mostly frontend cosmetics by just extending the user-selector UI. You can find it in the group-mention-branch of my github fork . It is very recent and should apply without many problems.

It has a security/privacy issue as is though, which is why I wanted to get back to you before sending a pull-request. We are exposing the full-list of users to any user with this feature, something that is currently not possible unless you are an admin and that can be of a privacy concern. My solution to that problem would be to add another configuration (“can be used as an alias”) with the following option:

  • 0 - can’t be used as an alias (default)
  • 1 - only admins can use alias
  • 2 - admins and group members can use alias
  • 3 - admins, group members and trusted users can use alias
  • 4 - everyone can use alias

And it would only show up accordingly. And maybe add the option to set a different alias to be used.

But before I go on: @sam, @codinghorror, would this approach of using only a frontend aliases work for you guys or should I drop this idea as you were planning to have a full implicit-group-mention feature (including all group-level-weirdness-problems)?

Happy holidays.

(Benjamin Kampmann) #4

I have another few days and a long flight ahead of me. I can most certainly get this done if anyone tells me that is an approach worth taking …

// cc @sam, @codinghorror

(Jeff Atwood) #5

I am not sure this is true? Unless I misunderstand what you are saying here. Anyone can autocomplete @name references to any known user in any post.

Regardless, I have no problem with groups as “giant list of named users” behind the scenes because isn’t that ultimately what it is?

(Sam Saffron) #6

I think the idea is to “optionally” under a very tall gated fence allow users to type @admins and have the mention go to all admins.

(Benjamin Kampmann) #7

Sorry that was not very clear. I meant that groups, their names and ultimately, who belongs to them isn’t exposed at the moment but would be with this new feature. Only admins can see at the moment, who is in which group. If I left the feature as is, we’d be exposing this – until now internal structure – to everyone. That’s why I proposed to have a configuration allowing the admin to define, who can use each alias, with a backwards compatible behaviour for existing groups.

Anyhow, from both of your answers I read a “sure, why not?” – so I’d go on with this and send a pull request in the next few days.

(Dan Porter) #8

Personally even if it runs the risk of abuse, if the ‘allow mentions of
groups’ setting defaults to off, we’ll avoid any inappropriate use.

(OT: I should really learn rails at this point, thanks for everything guys)

(Jacob) #9

Love this feature, I wish @admin and @staff didn’t include the system though.

(Sander Datema) #10

Is it? Just wondering what it should be now: when mentioning a group, that name is - like a TextExpander-snippet - expanded into all its members. This means if a group has 50 members, you get 50 @names in your post…

That’s how it works now. Though I’d rather have that single @groupname and have the magic happen in the background, like @codinghorror says.

(Benjamin Kampmann) #11

I was thinking of that, too. The reason I went for this implementation instead (aside from it being much simpler to implement), was that indirect-mentions comes with a bunch of more complications system-wise.

For e.g. we currently have a limit of mentions you can do per post, which has security and spam-related reasons. What does that mean for a group-mention? Does it count as one or as the representative many? In the first scenario, that means we allow spamming again, in the later how do we tell the user they can’t use it?

Another thing, right from the top of my head is when group members change. Mentions are static at the moment and we (as the system) only have to take of them when the post is created. If someone is added to a group (which is implicitly done by the admin and doesn’t need confirmation of the particular user), should they receive all former posts as mentions? And what if a post is added to a topic a “group” was mentioned in earlier? The tracking is currently bound to the User (which I consider the right way of doing it), this new user therefore won’t be informed. But should they be? And what if someone leaves a group? Doesn’t necessarily mean they shouldn’t track the conversation anymore. Having all these implications just because you join or leave a group sounds very inconvenient and unexpected consequences of that action for the user.

You see, this is all types of confusing and raises more questions about behaviour in implementation that we don’t have clear uses cases for yet. So whatever we’d decided it would be wrong. This approach is visible and clear. And by expanding the group, the users is clearly aware of their spam behaviour and can rethink it before doing so. For everything else, I think categories are the better use-case of separation.

(Josh) #12

Sorry to revive this but would mentioning a group work if its based on the user’s trust level?

(Erlend Sogge Heggen) #13

This feature has been implemented and is explained here:

(Erlend Sogge Heggen) #14