5ec47d99dc
* Ensuring we don't track views of author or unpublished Prior to this commit, I was surprised to learn that we: 1) Tracked an author's view of their article. 2) Tracked views of an unpublished article. This came up from a Forem creator asking if they could reset the view counter. Or trigger the reset on publication. I think a general business logic policy of don't track views for the author and don't track views for unpublished articles is a reasonable default. Were we to pursue the clear views on publication, we'd need to consider something that went from unpublished -> published -> unpublished -> published. Without a more explicit state machine, triggering a busineiss logic behavior seems a bit unexpected. In other words, I wrote an article. There are 20 views when I realize that I need to unpublished it. I make the changes in the unpublished state, and re-publish. I'd assume that those 20 views would still be "recorded" and counted towards my article's view counts. * Adjusting condition structure Prior to this commit, the `if` clause was rather far to the right. This helps make the if clause more pronounced. |
||
|---|---|---|
| .. | ||
| articles | ||
| badge_achievements | ||
| broadcasts | ||
| comments | ||
| credits | ||
| discover | ||
| emails | ||
| feeds | ||
| follows | ||
| github_repos | ||
| html_variants | ||
| listings | ||
| mentions | ||
| metrics | ||
| moderator | ||
| notification_subscriptions | ||
| notifications | ||
| organizations | ||
| pages | ||
| podcast_episodes | ||
| podcasts | ||
| push_notifications | ||
| rating_votes | ||
| reactions | ||
| slack/messengers | ||
| tags | ||
| users | ||
| bust_cache_base_worker.rb | ||
| bust_cache_path_worker.rb | ||
| capture_query_stats_worker.rb | ||
| data_update_worker.rb | ||
| export_content_worker.rb | ||
| migrate_data_to_work_field_worker.rb | ||