Mentioning non-user emails / altering @-mention functionality



Love your work Discourse team, keep it up.

I’m a journalist from Australia working on a Discourse-based platform for investigative journalism teams.

I chose Discourse because it offers thoughtful community management, email and Slack support, core-supported Patreon support and API write functionality for scrapers.

I’m also looking to integrate Freedom of Information (FOI) requests into topics ‘inline’ to allow teams to manage large quantities of requests in a structured Discourse forum.

By way of background, an FOI request is just a formal request to the government for information. They typically consist of two or three emails back and forth between a government department and a requester over a month or two.

So far I’ve got a ‘hacky’ version working by just creating users with the Freedom of Information contact emails and @-mentioning them. But the need to not ‘leak’ information means it hobbles the @-mention feature for other users.

I wondered whether it was worth considering an ‘@-mention’-like feature specifically for this purpose, ie something like an ‘^-request’.

Has anyone come across any plugins or extensions expanding or editing the @-mention functionality that I can review as a guide?

If not, I was going to start by hacking into here and here, but open to suggestions.

Thanks, appreciate your time.


(Jeff Atwood) #2

Can you elaborate on exactly how you see this working step by step? I am a little confused as to the desired workflow.

(Eli the Bearded) #3

I’m thinking you want to make the “Freedom of Information contact emails” into tags, not fake users.


Thanks Jeff, Eli,

There are a few alternative executions but this is how the simplest one would work:

That is, there is a separate category for ‘Requests’ and in each Request topic there would be a reply by email conversation with the external government department.

The first post would need a ‘trigger’ to direct the request to the relevant department. Subsequent posts may also need that trigger (unless it is ‘watched’ by the department).

Thanks again for your time.

(Eli the Bearded) #5

So, in this request category, somehow the first post is being mailed to the relevant external party and you want them to exist as a user so they can email directly back into Discourse?

That sounds… complicated. And risking that other things, besides these posts would be emailed.

(Jay Pfaffman) #6

I haven’t thought it through, but I think you might be able to do it by creating staged users and or having the agency reply to a category email address. Or start it as a group pm that gets converted to a topic post.

Perhaps you’d send the request to the agency with the category address in the from line, CC’ing the category.

I think the group thing could work, especially if you were content to have the start of the thread be the topic post.

Getting discourse to dupe someone into participating is the tricky part. :grinning:

(Dean Taylor) #7

Whilst the current (1.7) and very next release (1.8) doesn’t have the following features 1.9 is slotted to have the following which might be helpful:

Also note that Discourse 1.8 beta already has the following features / settings:

  • “enable staged users”
  • “Automatically create staged users when processing incoming emails.”
  • enabled by default.
  • “enable forwarded emails”
  • “[BETA] Allow users to create a topic by forwarding an email in.”
  • disabled by default.


Thanks Jay, Dean.

Having reviewed the options until 1.9 lands, I wonder whether I could just create a full user for each agency email address in the database, but with permissions to view only the ‘Requests’ category. Ie, all other categories are private to staff (or a separate custom group).

If the agencies actually want to sign into Discourse (ie by resetting their password), more power to them, but at least they have full reply by email functionality.

I’m happy for an agency to be able to see all posts under the ‘Requests’ category, even requests from other agencies.

This would also mean blocking all digests, but that might be a small compromise.

Can you see any other problems or security concerns with this approach?