Ability to add multiple topic timers

Hey all,

Is it possible to set up multiple Topic Timers – for example: publish, and then a separate one to auto-close the thread. I have a direct need for this…it’s not a deal breaker for it not to exist…just automation is amazing.

1 个赞

Is this what you’re after?

Auto-closing is already core.

1 个赞

Not possible right now as we only allow one public topic timer (publish, closing, opening) per topic. As a workaround now, you could set a publish topic timer and add a reminder for yourself to close the topic.

Could you build on your use case a little as to why you have a need for multiple topic timers? Multiple topic timers is not impossible but tricky to deal with as we now have to make sure that there isn’t any overlap with the time range.

4 个赞

I pretty much wanted a publish timer and a timer to close the topic automatically…not much more to it.

3 个赞

Here’s my use case for two topic timers on the same topic.

In my community, we have a recurring weekly topic called Wow Us Wednesday. It’s a 24 hour period for members to do self-promotion as we’ve found they need a time and place to vent their promotional steam.

We use the existing topic timer functionality to automatically close the topic 24 hours after being published – mostly so promotion stays contained to a specific weekly time frame and doesn’t keep bubbling back up to the top all the time.

However, using the auto close topic timer prohibits me from using the schedule publishing topic timer – and I want to use both.

I would prefer to schedule 4-8 weekly Wow Us Wednesday topics all at once from an efficiency perspective. Right now, I can’t use the schedule publishing topic timer as my one topic timer because, if I miss my window to manually close the topic 24 hours after it’s published, members can do self-promotion beyond our 24 hour concentrated time frame.

Since our Wow Us Wednesday takes place from 12:00 a.m. PDT - 11:59 p.m. PDT and I’m two hours ahead in CDT, I’d have to wake up at 2:00 a.m. to manually close the topic – something I’m not keen to do. That says nothing of my changed responsibilities if I’m on vacation, sick, or can’t find another admin in a different time zone to manually close the topic.

Having two topic timers on the same topic wouldn’t be revolutionary for me. But it would sure make my scheduling and team coordination easier, and I imagine hundreds of other Discourse users would say the same.

8 个赞

Interesting use case.

I think there is totally merit for supporting “delay published, auto closing” topics. I can see use cases where it is useful.

A current workaround is to post it to a category with auto-close topic hours set, would that not work?

5 个赞

I appreciate the workaround suggestion, Sam. I could see it working for some Discourse users … the issue is it doesn’t work for mine.

The self-promotion threads are published to a category called “Anything Goes” and the nature of the category is to have wide-ranging conversations. The only forum threads in the category I’d want to auto-close are the self-promotion focused ones I publish. The rest are published by community members and I want to leave replies open indefinitely.

Granted, I could create a new category specifically for these weekly self-promotion posts. But we’re wary of the communication and UX tradeoffs when we create new categories and try to do it as infrequently as possible.

2 个赞

How about a “wow us Wednesday” subcategory of “anything goes”?

3 个赞

Stephen, we played with the idea of having a “Wow Us Wednesday” sub-category of the “Anything Goes” master category. However, despite the efficiency gain of being able to have a dedicated sub-category with the ability to auto-close all topics in it after 24 hours, we weren’t willing to make the trade off in UX.

For example, having a sub-category filter in the Anything Goes category for the Wow Us Wednesday sub-category and seeing the standalone Wow Us Wednesday sub-category on the the Categories view page (e.g., https://yourforum.com/categories) draws too much attention to the fact that we have a dedicated sub-category for self-promotion.

Our goal is to limit the visibility of self-promotion for the 144 out of the 168 hours each week where we’re not actively doing self-promotion.

I’m grateful for the suggestion. I’ll just wait until @sam or someone else on the Discourse Team develops the “delay published, auto closing” feature Sam mentioned he’d like to see.

3 个赞

Did you experiment with hiding that particular subcategory from /categories using css?

I have another use case for publish-then-close: I am running a course, where we are posting announcements inviting input for each course activity, and afterwards closing the announcement after the corresponding activity (lecture or Q&A) is over. An auto-close category wouldn’t quite work because different activities have different expiration.

3 个赞

Hi, tried to setup multiple timers for recurring events. Allowing 2 - 3 would be useful!

  1. Delayed Publish
  2. Delete All Replies after 7 days
  3. Auto Bump weekly, or bi-weekly, before the event recurs.

Thanks for considering. Also using new automation plugin to:

Auto-Pin topic the day before next occurrence. Hoping to eventually set this as recurring weekly / bi-weekly / monthly rather than on a specific day. ← This how we’ve configured our Event plugin.

Perhaps there could be more interplay between topic timers and the automation plugin in the future. Cheers.

Another topic timer option that could be useful:

  • Remove all emoticons from topic.

This is because users like to use emoticons to interact with a topic when they agree / disagree, etc.

2 个赞

That belongs in the event plugin IMO.

2 个赞

我的用例是用于游戏帖子。

我想在午夜启动一个锁定的帖子,因为人们会从我们为期一周的活动博客开始寻找它。这个我可以做到。

我想在游戏实际开始的上午 9 点解锁它。我唯一能做的就是熬夜到午夜之后设置另一个计时器,或者在上午 9 点手动设置。

另一个用例是赠品帖子。我希望能够同时发送开始和结束时间,而不是等到帖子发布后才设置结束时间。

我非常希望能够设置两个计时器。我可以看到这可能会有点棘手,如果它们发生冲突,但也许可以限制用例或加入一些检查和平衡。

谢谢!

5 个赞

这是否可以拆分为一个针对自动关闭的计划帖子的特定 RFE?

具有自动关闭类别的变通方法总的来说是有意义的,但我希望在接下来的几个月里,针对特定的一组对话进行此操作,作为结构化讨论的一部分,而为该对话设置一个单独的类别似乎过于繁重。

为什么不将其设为一个单独的子类别?这不算太糟糕,而且你可以对其进行配置,这样你的用户可能根本不会注意到。

我的用户非常喜欢留意。 :slight_smile: 许多用户设置了过滤器来对他们的通知邮件进行分类,因此对类别更改很敏感。

我也对子类别的通知设置如何工作感到不确定……如果我创建一个子类别,它会继承父类别的现有用户设置,还是他们需要单独订阅?

呃!!!你需要将它们从邮件列表模式移到 Discourse UI!我知道这并不容易,这是我从实际经验中得出的。祝你好运。

邮件主题标签将包含父类别的名称,但这取决于他们如何设置他们的过滤器(特别是如果他们同时包含方括号)。

这有点复杂——在设置通知默认值时有一个继承功能,但我没有弄过。如果你愿意,你绝对可以独立设置它们。