If you're using our New and Updated callouts to trigger subscription emails, we have an important functionality update for you:
We've had a couple customers run into a workflow hiccup when they were adding callouts. Here's the scenario, in case it applies to you:
- You edit an article in one of our Draft publishing statuses (Draft, Ready to Publish, Rejected Draft).
- You add a New or Updated callout while the article is in that status, and save.
- You later save the article with a Published status.
In this scenario, people expected that the subscription notification email would trigger when they added the Published status. But what actually happened was: it got ignored. This is a combination of two factors: when you first add the callout, we add a flag to the article so the subscription job can find it; but the subscription job never saw that flag since it ignores Draft articles. Once you published, you'd have to manually remove/re-add the callout for a subscription to be sent. Not the best experience!
We debated various solutions here, like not allowing you to set the callout until it was published, but that just seemed...silly.
Instead, we decided to make the Publishing process a little smarter.
Now, given that same scenario above, once you re-save the article with the Published status, we reset the callout flag using the timestamp of when you published. This effectively adds the article into the subscription notification queue the next time it runs. (It does not touch or make any changes to your status expiration date for that callout, though, so if the status has already expired, you'll need to re-add it!)
So now, you are welcome to add callouts to draft articles if you know you'll be publishing them soon, and you can trust that the subscription notification email will go out properly. Whew!
Other bug fixes
We also released fixes for a couple other bugs:
- With Widget 2.0, we noticed that Widget reporting was not updating learned bias. We've fixed this.
- If you left unsaved changes in Settings > Style and navigated somewhere else in the app, we noticed this was causing some view issues with the homepage. We've fixed this; you should always be welcome to abandon unwanted/unsaved changes in Style Settings.
