Issue: Notifications not always working

From what I can tell by looking at the notification code, yes it should show notifications from subareas too. However, it looks like there is a problem if you have subscriptions for multiple nodes if those nodes would trigger notifications for the same event.

It appears that only the first subscription that is found in the database would be used, when in fact you would expect the most qualified subscription to be used. In this case, if the most qualified subscription is used and it's not configured to trigger an alert, then the user would not receive one. However, due to the current broken stacking, if you have a different kind of notification selected for one or more of these stacked subscriptions (such as weekly email), it's possible that it would not trigger an in-site alert simply because the wrong subscription is used to send the notification.

I have to do some more investigating to determine just how unexpected the behavior can become, and what the best way to correct it would be.

As for notifications of the entire wiki, it's not clear if it's related to that issue or if notifications just don't reverse all the way up the chain back to the index (I have a feeling it only works as expected for scheduled emails, if at all).

If your default subscription mode is not being honored, then of course it would be compounding the first problem I mentioned. If it's really not being followed, then this is the first thing to fix since it will make debugging easier if fewer subscriptions are being made and it's important not to make users angry by auto-subscribing to things that they intended to be opted out of.

The following problems were occurring:

- Instant notifications (including in-site alerts) were only being sent for changes that affected the subscribed page directly
- In-site alerts were not being sent for updates to pages (only comments and only for subscriptions to the same discussion/page)
- When the user had multiple subscriptions affected by the same update, a random subscription was used to handle notifications, rather than the most specific one.
- Notifications were not being sent for child-updates for index subscriptions.
- Only new pages were triggering child-update notifications for other subscriptions. This was partially by design to avoid "there was a new edit in Area X, (but really the edit is for page Y in sub-Area Z of Area X)", but I think the expected behavior is for everything to trigger child-update notifications.

All of the above are now fixed. When you start overlapping these issues, you would find that most notifications just never got triggered. Only some of these issues are fixed on your site at this time. There were just a lot of changes, so I didn't manually apply them all.

Still looking into your issue with default subscription modes.

The actual problem with the default subscribe mode was that the Wiki Preferences page was not always showing the correct value for your current subscription mode setting. In some cases, it would show "Do Not Subscribe" even though the user had "Instant Notifications" turned on. This is now fixed by showing the correct value in the preferences for the specific cases that were broken.