Post scheduling

[ludwiczakpawel]

TL;DR

Let users schedule their post's publication date and time.

Description

Add a UI control (ideally input[type="datetime-local"] as it comes with browser's native handy controls for date and time picker) to let authors schedule their posts instead of immediate publishing. The flow is visualized in the Figma mockup.

Additionally, this will require also tiny changes elsewhere:

• Article view: once you schedule a post you should be able to see it as well, similarly to what happens when you save it as a draft. Let's utilize that message on top of the post to show appropriate message, e.g. "This post publication has been scheduled for mm-dd-yyyy, hh:mm" or something like that :).
• Dashboard: we may need to add extra badge there to indicate that a post has been scheduled.

Resources

• Related Slack Thread
• Mockups

[github-actions]

Thanks for the issue, we will take it into consideration! Our team of engineers is busy working on many types of features, please give us time to get back to you.

Feature requests that require more discussion may be closed. Read more about our feature request process on forem.dev.

To our amazing contributors: issues labeled type: bug are always up for grabs, but for feature requests, please wait until we add a ready for dev before starting to work on it.

To claim an issue to work on, please leave a comment. If you've claimed the issue and need help, please ping @forem/oss. The OSS Community Manager or the engineers on OSS rotation will follow up.

For full info on how to contribute, please check out our contributors guide.

[JennieOcken]

FYI: #15473

[lightalloy]

I described my ideas in a forem team post, and we had a productive discussion in the comments section.
Let's break down the feature:

Make it possible to set published_at field to the future

• change the validation

Setting published_at from editor v1

• Frontend: setting the default published_at similar to other fields, and passing it when submitting a form. I suppose that the default value may be commented similar to the cover_image.
• Backend: parse from frontmatter, make sure that published_at is set
• don't allow to update published_at when the post has been published already (backend)
• Take user's timezone into an account

Setting published_at from the rich markdown editor

• add a datetime picker to the post options
• make sure that the date from the datetime picker is passed correctly and saved
• don't allow to edit published_at in the post options when the post has been published already
• don't allow to update published_at when the post has been published already (backend)
• change the button label from “Publish now” to “Schedule” once the schedule publication date is set. Additionally, show tooltip on hover.
• Take user's timezone into an account (pass the timezone data to the server implicitly or explicitly)

Modify logic related to actions we do after the publication (notifications, mentions, slack notifications)

• create a notifications registry
  ContextNotification model (action - name of the notification, context_id, context_type - article)
• track sending slack notifications and creating mentions - I think that we can do without explicitly tracking creating mentions and sending slack notifications for now

Option 1. "Quick" fix

When a post is scheduled to the future:

• schedule a Notifications::NotifiableActionWorker. to run at a certain time
• modify the worker to check if published_at is in the past and whether the notification has been sent already
• on update: if the user later changes published_at to another date in the future, schedule another job to that point in the future + unschedule the previous job (if that's possible)

The "quick fix" solution includes redundant jobs, or unscheduling jobs which is undesirable.

Option 2. "Long-term" solution

• create a worker that will:
  • find articles that were published (because published_at time has arrived) but no actions related to notifications were taken
    for those articles:
  • send slack notifications
  • create mentions
  • create notifications
    We have the code that performs these actions already, but we need to reorganize it: remove from Articles::Creator and Article callbacks.
• Schedule the worker to run

Display scheduled articles

• user dashboard: add status indicator and maybe little change in action buttons
• make sure that scheduled articles are not displayed in feeds (this should work already because filtering by published_at is already present in the published scope)
• article show (add a red notice similar to draft's one)
• make it possible to preview scheduled posts (same as drafts)
• render 404 when attempting to view a scheduled post by its url w/o preview key

Admin articles page #15859

Currently, only published articles are listed on the /admin/content_manager/articles page.
If we need to view/edit scheduled articles, we'll need to create a separate page/section for that.

• add a state indicator on the articles page (/admin/content_manager/articles)
• change "Published at" to "Publish at" (/admin/content_manager/articles) for scheduled articles
• setting featured (/admin/content_manager/articles) - I think we may keep the field as is and make sure that scheduled posts don't appear as featured
• setting approved (/admin/content_manager/articles) - I think we may keep the field as is and make sure that scheduled posts don't appear as approved in tags (they shouldn't already)
• pin post - we should make sure that we don't allow pinning scheduled posts, and hide the corresponding buttons on the admin page (/admin/content_manager/articles) - only published articles appear in /admin/content_manager/articles + PinnedArticle.pin also checks for only published articles, so, there is probably no need to restrict pinning at this point
• don't allow to pin scheduled articles on users page (post => manage)

A Feature Flag

• add a feature flag to enable/disable scheduling (interface), put related logic behind it

[lightalloy]

It seems like "quick fix" and "long term" options are not that different in terms of the time needed to implement, so I lean toward the "long-term" solution. Also, there is a large part of the feature that doesn't depend on what solution we choose.

[amywtlin]

I agree. Let's go with the long-term solution. Thank you @lightalloy!

[lightalloy]

The feature is merged, but remains behind a feature flag. The next steps are:

• Improve the datetime picker Improve the datetime picker for scheduling posts #18075
• Refactor saving published_at logic

[mirie]

@lightalloy can you remind me -- In your last comment there's a checkbox for Refactor saving published_at logic. Is that still a pending task?

[lightalloy]

@mirie yes, it's pending, sorry for the late response.