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?
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.
https://github.com/discourse/discourse/blob/tests-passed/spec/models/topic_spec.rb#L1087
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.
https://github.com/discourse/discourse/blob/tests-passed/app/models/topic_converter.rb#L10
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