Doc clarification: notification behaviour for staged users when posts are moved

AI-generated summary

Ethsim2 highlights a documentation gap regarding notification behavior for staged users when their posts are moved by moderators. Although staged users automatically receive “Watching” status for the topic they post in via email, this status does not transfer if their post is moved to another topic — meaning they may miss replies unless they manually subscribe or post again. This can mislead moderators, especially in support workflows, and degrade user experience due to unclear expectations. The suggested fix is to clarify in documentation that notification settings are topic-bound, not post-bound, and optionally add a UI prompt to transfer notification status during post moves. Ethsim2 adds context on reply-by-email behavior: reply keys are tied to both the post/topic and the sender’s email address. If a reply is sent from a different address than the one the key was issued for, Discourse rejects it with an error (e.g., email::Receiver::ReplyUserNotMatchingError) to prevent impersonation. This contrasts with staged user creation via category emails, which does not require matching addresses — only reply keys enforce sender verification. This distinction is critical for understanding how staged users and reply-by-email systems behave differently under moderation actions.

What is the issue?

The discourse around staged users implies they will receive email notifications for replies to topics where they’ve posted by email. However, when their post is moved to another topic by a moderator, the documentation does not clearly explain how their notification status (e.g. “Watching”) applies to the new topic. As a result, it’s easy to assume they’ll keep getting replies in the new topic, but that isn’t always the case.


Current behavior

  • When a staged user posts via email, their notification level for that topic is automatically set to Watching.
  • If a moderator moves their post into a different topic, the staged user remains “Watching” the original topic.
  • They do not automatically begin watching the destination topic, so new replies there may not generate email notifications for them, unless they otherwise become subscribed or post again in the new topic.

Why this matters

  • Moderators working with staged users (especially in support forums or helpdesk workflows) may assume the user will keep getting responses even after a post is moved.
  • Because the behavior is not clearly documented, replies can be missed, which may degrade the user experience or missances of communication.
  • Clear documentation would help community admins and moderators understand what to expect and manage staged users appropriately (e.g., manually adjusting notification settings).

Suggested resolution

  • Doc clarification: Update the staged users / email-in documentation to explicitly state that notification settings are tied to topics, not to posts, and that moving a staged user’s post to a new topic does not transfer “Watching” status automatically.
  • Optional enhancement: Provide a UI/setting so that, when moving a staged user’s post, moderators are prompted (or given the option) to also transfer the notification state (or subscribe the user to the new topic) so they continue to receive replies in the new topic.
1 Like

Just to add a clarification about reply-by-email behaviour (since this sometimes comes up in the same context as staged users and moved posts):

Each reply-by-email key is bound both to the post/topic and to the email address of the intended recipient.

If someone forwards or shares their reply-by-email key with another person, the second person will not be able to use it. Discourse checks that the From address on the incoming email matches the address that the key was issued for. If it doesn’t match, the mail-receiver bounces the message back with an error like:

We’re sorry, but your email message to
reply+8ea3c4377a64fd24270449c9815ae5e7@discourse.example.com
didn’t work.
Your reply was sent from a different email address than the one we expected, so we’re not sure if this is the same person. Try sending from another email address, or contact a staff member.

This ensures reply keys cannot be passed around as a way to impersonate another user.

By contrast, when you’re dealing with staged users created from incoming mail (as in the OP), those are handled differently: if auto-create staged users is enabled and the message is sent to a category address (not via a reply key), then Discourse will happily stage a new account for that sender. But reply-by-email keys always require the sender’s address to match the originally issued key.

From: Ethan’s Community reply-to-me-by-email@discourse.REDACTED.com
Sent: Thursday, September 11, 2025 7:34 pm
To: ethan.tees@btinternet.com ethan.tees@btinternet.com
Subject: [Ethan’s Community] Email issue – Unexpected Reply Address

We’re sorry, but your email message to [“reply+ancdc4377a64fd37s25449c9815ae5e7@discourse.REDACTED.com”] (titled test any subjective) didn’t work.
Your reply was sent from a different email address than the one we expected, so we’re not sure if this is the same person. Try sending from another email address, or contact a staff member.

Error in admin logs: email::Receiver::ReplyUserNotMatchingError