Embedded topic goes to Uncategorized

This might be related to Embedded topic split bug (500's) - 1.8.0 beta 4.


  • running Discourse v1.9.0.beta8 +115
  • I created an authorization for a host with pattern /zoethical/ and a specific category to assign topics from web comments.
  • the site owner created /zoethical/index.html with discourseEmbedUrl: 'https://nethood.org/zoethical/'
  • he added a comment for testing… The comment appeared in a new topic under the Uncategorized category.
  • I moved the topic to the right category.
  • The topic has the mention: This topic will be closed after 7 days. according to the settings in Uncategorized.
  • Important note that might affect the bug reproduction: the target category is a sub-category with permission restrictions, so that people using the embedding feature can discuss without polluting that main topics. The sub-categories have default permissions.


  • The topic should be created in the right category.
  • When the topic is moved, it should comply with the auto-close settings of the new category.

Unfruitful Steps Towards Resolution

I tried several things:

  • moving to a new conference and adjusting settings in Admin > Customize > Embedding
  • setting auto-close for the category, then resetting
  • change the pattern from /zoethical/ to /zoethical/.*

Nothing works.

Is there a way to fix this from the console?

What is the proper way to set a pattern for a sub-directory on the remote server?

I traced back the problem to the topic_spec.rb where it says a topic with an existing topic timer when moved to a new category should not inherit category’s auto close hours.


If it makes sense when moving a topic from an auto-close category to another, although the rationale remains unclear, it seems on the contrary to be logical to remove the topic timer when moving it to a category that does not have a topic timer.

The use-case I’m referring to is the following: I have a private conference set with an email-in and a topic timer where I throw all kinds of stuff I find interesting online. The topic timer allows to quickly ditch what is not picked up and keep an archive in case someone wants to resurrect the topic. If a topic is picked up, it usually evolves into an article, which is at some point moved to a public category with no topic timer. There, I would expect the topic to lose the topic timer, and there’s no UI to remove it forcefully.

The only way to do it currently is to copy-paste the article into a new topic, losing the history and link to the original topic. So instead, there should be a revised specification added to that portion of topic_spec.rb:

  • #change_category_to_id
    • with a previous category
      • to a different category
        • when new category is set to auto close by default
          • when topic has an existing topic timer
            • should not inherit category’s auto close hours
        • when new category has no topic timer
          • when topic has an existing topic timer
            • should remove topic timer

An alternative would be to add a UI element to remove the topic timer, but this would be an expedient as it would not work with the API.

I see that the fact a topic is moving from a private category to a public category also affects resetting the topic timer in the above use-case. In the convert_to_public_topic method below, the Topic.transaction should then check for the state of the timer.


I also realize that topic timer might not be the right term in this case. I found the topic_timer model but it seems to be used for other things as well, like auto-publishing to a category on a given schedule. This one sounds great, I had no idea Discourse could do that. Any pointers?

1 Like