Feature Request: Auto-extend a topic when an email's subject matches its title

Feature
1

Currently, if two mails with the same subject line are sent to a given Discourse category, each one creates its own topic with the subject line as its title. This ends up creating multiple topics with the same title, regardless of whether or not the “Allow topics with identical, duplicate titles…” configuration options are selected, which can have the effect of resulting in a multitude of topics with the same title.

Here, what I’m requesting, is for such mail-generated posts to automatically be merged into an existing topic when they share its subject line if the “Allow topics with identical, duplicate titles if the category is different” option is unchecked (or by adding a new “merge posts sent by mail into an existing topic when its subject matches the topic’s title” option). This would have the benefit of avoiding duplicate titles in a category while also permitting multiple mails to accumulate in a single topic when they share a subject line (whether by design or accident).

In practice, this comes up for us when we have scripts that generate posts that are intended to be related to one another under a single topic like “such and such a testing configuration failed” or “someone mentioned xyz on reddit”. It would be ideal if all mails sharing such a subject were grouped under a single topic rather than creating a new topic per mail, each with an identical title. It would also let someone add a new post to a given topic by email without necessarily having to reply to a mail notifying them of a previous post to that topic, for people who might need to write by mail rather than via the web interface for one reason or another.

I think the potential for downsides in cases where humans accidentally send in mails whose subject happens to match an existing topic that they were unaware of is low. Mostly because I presume that if their subject line happens to match a pre-existing topic’s title, it’s due to a similarity of content, so it doesn’t seem like a big problem to have it extend the existing topic rather than create a new one with a duplicate title. Moreover, a site administrator could always check the “allow topics with the same title…” checkbox if they did want the current behavior of having each new mail create a new topic.

This feature would be incredibly useful to our Discourse site, and I suspect likely to others’ as well. Thanks for your consideration, and for all the great engineering that has obviously gone into Discourse.

2

I think this is very community specific, by your own admission unintended collisions would occur. What value is there in having a smaller number of much longer topics?

For communities such as meta this would mean that any user who emails in with ‘problems configuring mailgun’ will continue to be notified of updates months or years after solving their issue. That doesn’t sound practical.

The goal is to avoid duplicate titles, which the current setting enforces for topics created on-site as the user can be given feedback at the time of topic creation. The setting isn’t respected for users emailing in because there’s no such opportunity.

3

Thanks for engaging with me on this, @Stephen.

I think this is very community specific

I agree. That’s why I propose that it be controlled by a settings checkbox (whether by re-using one of the existing ones relating to not permitting duplicate titles or adding a new one).

What value is there in having a smaller number of much longer topics?

As background, on our Discourse site, we have a “Notifications” category, each of whose subcategories receives mails that are sent by scripts when certain events occur (e.g., testing failures, new issues filed, new Stack Overflow questions posted, new mentions of our project on discussion sites, etc.). These categories are designed to permit community members to track and discuss particular types of events that they may be interested in.

In some cases, the mails generated by our scripts have predictable, deterministic subject lines by design, such as “linux64 testing”. For example, if we have a new failure in our linux64 testing on August 15th, that generates a mail. If additional failures creep in on August 16th, that generates a second mail with the same subject line. Then if all the failures are resolved on August 17th, a third mail with the same subject line is generated indicating that resolution. Then if we have new failures on August 31st, we generate a fourth mail with the same subject line, and a fifth when the failure is resolved.

With the current site behavior, each of these mails generates a brand-new topic named “linux64 testing” with no linkage or relationship between them, making it difficult for humans to correlate the events or decide which of the five topics they should use for follow-up discussion about the failures. Whereas what we’d like is for all five mails (and any user discussion that transpires on them) to appear as posts within a single topic so that a developer can look at all testing failures in a given configuration within a single topic, organized chronologically.

Another impact of the current Discourse behavior is that someone who is receiving email notifications for the category or topic in question sees five unrelated threads in their inbox named “linux64 testing”. Whereas if Discourse were to merge these into a single topic, that person would see all the “linux64 testing” posts associated as a single thread within their mail reader, making it far easier to navigate and much more like any traditional conversation.

We run several dozen testing configurations each night, each of which has a unique subject line when failures occur, so the current situation results in something of a sprawling mess which is hard to navigate, with a distinct, shallow topic per mail, all interspersed chronologically. Whereas, our ideal would be for the “Notifications.Tests” category to show a single topic per configuration which stores all human or script-generated posts about that configuration chronologically, as determined by that unique subject line.

[This testing category isn’t currently publicly visible on our site @Stephen, but if you’d like to see what it looks like and feel the pain firsthand, I’d be happy to temporarily grant you read access to it…just let me know.]

For communities such as meta this would mean that any user who emails in with ‘problems configuring mailgun’ will continue to be notified of updates months or years after solving their issue.

I agree that this choice may not be as sensible for a community as large and long-lived as meta that doesn’t have a need for aggregating mail-generated posts into a single topic as we do. So you probably wouldn’t want to opt into such a feature if it existed. (And maybe over time, a site like ours wouldn’t want it either for the same reasons, in which case I think the ideal would be to be able to apply the checkbox on a per-category basis, but I didn’t want to ask for too much when I believe that a single site-wide setting would suffice for us at present).

That said, even if a site like ours were to opt into such a feature, and the original poster of the ‘problems configuring mailgun’ topic was annoyed by subsequent posts that shared the same subject line, presumably they could unsubscribe from the topic in order to avoid continuing to receive updates if/when someone else uses the same subject line (or simply adds another post to the given topic via the web interface)?

[That said, I expect that most human users will post via the website, so imagine this feature having a bigger impact on script-generated posts than human-generated ones]