Issue: Notifications of article edits when article is watched

AFAIK email alerts are already handled, but I agree that new edits should also show in the UserCP.

This issue corresponds to a Subscription UI task that we would have added for VaultWiki 4.0.0 Alpha 1. When the UI and digests are completed, I will mark this as complete. This is currently In Progress.

This task has taken a bit longer than anticipated due to a number of issues:
Subscription management / viewing is just one part of the process. The other part includes automated (email) subscription notifications:

• While cron jobs existed in VaultWiki 3 to handle this, it was mainly integrated into forum/thread/group subscriptions. There are a LOT more content types than this in VaultWiki 4, and we needed to design a system where each "node" content type could handle new items of each "item" content type. Of course, we also wanted developers to be able to create their own content types, and we didn't want to create a 3D or mirrored file system where subscribe > node > item, where each item type had to be specifically programmed for every possible node type. This expects developers to create too much code. This presented one engineering problem where we had to figure out a simple way to design the system that would work with all content types if they were in turn designed correctly.
• Notifications and subscription viewing requires filtering nodes by their last update. While we created all the necessary update counters in the database, there was no code that populated the tables in any data managers. While updating all the data managers and attempting to make all the updates efficiently applied to all parent nodes for all updated items simultaneously, we discovered serious design flaws in some previously "finished" DMs:
  
  • pagecount and other types of counters were not updated correctly if the visibility of content changed. A particularly problematic example was: Soft-delete an article, then restore it at a later time. Revisions for a soft-deleted article should not be included in the edit counts for the article's parent nodes, and likewise, a restored article should have its edit counts restored. Because of multiple parent-node possibilities (Areas, Books, Categories, Groups, etc), updating these all efficiently became another engineering problem.
  • Specifically the DMs for attachment edits and page edits were horribly broken and inefficient. They didn't allow for mass deletes or mass rollbacks.

After dealing with all of this, and over 40 new files later, we have finished the subscription system insofar as VaultWiki knows what to do with subscriptions for them to have utility. However, it has yet to be told how to create, organize, and manage the subscriptions themselves. Thankfully, that should be the easy part.

Finally done with this. Back to node handling.