Embedded topic goes to Uncategorized

hellekin · September 14, 2017, 12:29pm

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

Situation

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.

Expectation

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?

hellekin · September 29, 2017, 8:30am

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.

github.com/discourse/discourse

spec/models/topic_spec.rb

tests-passed


      
                expect(pm.invite(user, user1.username)).to eq(true)
              end
            end
          end
          
          describe "by email" do
            it "should be able to invite a user" do
              expect(topic.invite(user, user1.email)).to eq(true)
              expect(topic.allowed_users).to include(user1)
          
              expect(Notification.last.notification_type).to eq(
                Notification.types[:invited_to_private_message],
              )
            end
          
            describe "when user is not found" do
              it "should create the right invite" do
                expect(topic.invite(user, "test@email.com")).to eq(true)
          
                invite = Invite.last

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.

github.com/discourse/discourse

app/models/topic_converter.rb

tests-passed


      
          # frozen_string_literal: true
          
          class TopicConverter
            attr_reader :topic
          
            def initialize(topic, user)
              @topic = topic
              @user = user
            end
          
            def convert_to_public_topic(category_id = nil)
              Topic.transaction do
                category_id ||=
                  SiteSetting.uncategorized_category_id if SiteSetting.allow_uncategorized_topics
          
                @category = Category.find_by(id: category_id) if category_id
                @category ||=
                  Category
                    .where(read_restricted: false)
                    .where.not(id: SiteSetting.uncategorized_category_id)

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?

Topic		Replies	Views
Automatically move topic category after topic close Feature	6	873	September 4, 2025
Autoclose doesn't update when you change the topic category Bug	2	492	March 11, 2022
Topics carry automatic close settings when moved to another category Feature	3	652	September 7, 2018
Auto-close topic timer in category settings doesn't undo when moving it to another category Feature topic-timers	1	377	July 12, 2022
Topics moved into auto-close-able categories should autoclose Bug	4	1320	June 2, 2017

Embedded topic goes to Uncategorized

Situation

Expectation

Unfruitful Steps Towards Resolution

Related topics