"Body too Similar" Compares Posts and Message

bug
1

“Body is too similar to what you recently posted”

I use a message-to-self as a drafting buffer for elaborate posts that I’d like to publish privately before posting. (The main reason being that the preview pane doesn’t always render the same as the published post/message, so I have to publish to see the final form. Publishing in private also allows me to avoid the “edit window” time limit before emails are sent out after a post or topic is first published.)

When I tried to paste the body of the message into a forum post, I got the “Stop spamming everyone with the same content” “Body is too similar to what you recently posted” message. Given that a user can delete a message, this seems like an unnecessary check. Also, I might send a message to someone and then want to convert it to a reply post (maybe I asked them to proofread it, for example).

I’m not talking about converting a message into the first post in a topic. I’m talking about appending a message to an existing topic. I don’t know squat about the Discourse DB structure and how different a post and a message might be. Since it’s possible to strip a message of its ‘messagey’ attributes and dress it up as a topic, it seems like a similar process would be possible to convert it to a reply.

At the very least, I’d like to be able to reuse the message body in a post.

There might be a mention of a workaround HERE but I’m not able to parse the OP’s process clearly enough to know.

1 Like
2

I’m afraid I don’t think this can be considered a bug, as it seems to be working correctly. :slightly_smiling_face:

It’s controlled by the unique posts mins admin setting (default 5 minutes), so you could ask the admin to reduce it if the wait is causing significant issues?

4 Likes
3

Excellent back-of-house insight, as usual!

By the time I got back to discuss.python.org, the timer had expired and I was able to post the body of my final “message” draft. Had I not been stopped in my tracks on the first duplicate, I wouldn’t have posted here. (That somehow reminds me of the ‘snake eating its tail’ meme. :upside_down_face: )

I’m afraid I don’t think this can be considered a bug, …

Yes, it does seem to fall somewhere in between. This query is about why the first duplicate in a different platform object type would be blocked in the first place. It seems to be a case of trading a solution for a different problem (albeit a lesser one, so the ‘feature’ aspect of this behavior is a net plus as a guard against nuisance posting and messaging). Nevertheless, it seems incongruent and therefore inapplicable to compare a post body with a message body since they have such different scopes.

…since it seems to be working correctly.

I agree, as long as we define ‘working correctly’ to mean “as intended” and this was a design decision rather than an oversight or unintended behavior, which are both a type of bug. :smiley: I didn’t see it posted in features (or discussed anywhere else) and figured this was an appropriate place to report on existing nonoptimal behavior.

Just as any bug you don’t know how to fix becomes a “feature” by default, any “feature” that gets in the way can be considered a bug.
Waiting for the unique posts mins to expire is even a workaround. :point_left: :stuck_out_tongue_winking_eye:

I didn’t have to wait especially long to post the message text, but it does throw a hard stop into the flow. Maybe I’m the first user to try moving content from message to a topic reply. :person_shrugging:

4 Likes
4

I’m a big fan of the ‘pm-as-draft-message’ approach, and have had a number of these warnings too. Perhaps I have been too accepting of the status quo. :slightly_smiling_face: I don’t know how popular this workflow is, so we may be in the minority, but we could make this a #feature request?

Alternatively, on a more minimal scale, a #ux approach could be to include more information in the warning message (eg. “Body is too similar to what you recently posted. Try again in %{unique posts mins}”). This may at least emphasise that it’s time-based and only a temporary restriction (though possibly undermining the intent?).

5 Likes
7

This is indeed an effective and simple (and therefore excellent) enhancement. I’ll submit it as a separate feature request.

3 Likes
8

I think @codinghorror has been quite a fan of using PMs for long drafts, having it block yourself is not our intention here:

There is a very simple fix/change in Discourse:

Swap to:

    def unique_post_key
      "unique-post-#{user_id}:topic?.private_message?:#{raw_hash}"
    end

That plus a quick test will fix this workflow.

I do not thing safety guarantees are hampered by this change.

Will go ahead and make this change tomorrow unless there is an objection.

4 Likes
10

Thank you, Sam!

Will this be in a release soon? I tend to compose longer replies at discuss.python.org than here–and also proof and revise more extensively since the discussions are about technicalities with lots of opportunity for misstatement and typo goofs when posting untested code.

2 Likes
11

We have a fix in the pipeline at:

It should be merged soon and site will be deployed in the next couple of weeks.

In the mean time I recommend an easy work around. Just do quick “space padding” when you go to post your draft.

Both

hello world and

hello        world

render the same in markdown

hello world.

2 Likes
13

This topic was automatically closed after 4 days. New replies are no longer allowed.