Issue: Notification of unreviewed edits, for wiki moderators

Okay for this:

1. A moderator table to define who is a moderator. Any user added to the table is also added to the wiki-moderator usergroup. That usergroup actually gives them permissions. Conversely, for this to make any sense, moderator permissions should only apply to a user if they are in the moderator table for that node.

2. The moderator table is used to efficiently get a list of moderators when a change is made, rather than attempting to check all users for moderator permissions. When an item is added to the moderation queue, it adds an entry (or several, if the node has multiple parent nodes) to a separate queue table. If the item is no longer moderated (deleted, approved, unapproved), the corresponding entries are removed from the queue table.

3. Additionally, the moderator table contains settings that can be adjusted in the UserCP. For each node they moderate, whether to notify the moderator via email when the queue entry is created, and/or via on-site notification whenever they log in.

4. When the user is logged in, on-site notifications need to be constructed. To avoid an extra query, this will assume you actually gave the moderator group permission to moderate. First we check if they are a member of the wiki-moderator group. If they are, query the moderator table to get the nodes they moderate (where they have asked to be notified on-site) and join the queued items that fall under that node. Store the nodes the user can moderate in their userinfo in case we need to verify their permissions later. Count the number of each item type that is moderated, and output those numbers as notifications.

This is not actually done. This was an outline to make sure I had a sane idea of how to set this up without adding too many queries. Looks good to me.

Completed #2, so the queue is created/updated and email notifications are sent out for moderators with that option selected. Will continue this in a bit, working on Special pages now.

Completed moderator DM and moderator import. There was an initial issue importing moderators because we could not clone the same query as admincp/moderator.php to obtain the moderator list. This query causes a full table scan on 'user' and is bad news for forums. We reported it to vBulletin: http://tracker.vbulletin.com/browse/VBIV-13150

For this we expanded database abstraction to handle unions, although we opted to use 3 separate queries for the import because order was not important, and this avoided MySQL using temporary tables.

Note that #1 requires updates to the current implentation of permissions to work. An equivalent for can_moderate is needed rather than simply checking if the user has bits filled. Additionally, this requires buffering the results of permissions fetching so that the permissions can cascade appropriately. Which has the added benefit of allowing us to fetch permissions for multiple users and nodes in the same query.

Will update again once this is handled and #1 is complete.

#1 complete. The permissions model now supports pre-caching and recalculates the final bit values from the cache each time permissions are fetched. This allows us to check if the user is a moderator on each node if, for example, permissions are being inherited from a node the user can't moderate.

#3 deferred to handling by: https://www.vaultwiki.org/issues/2456/
Which will allow us to close this issue sooner.

#4 complete. However, the Edits Awaiting Moderation page in the ModCP needs an overhaul to show multiple item types, filter by type, and use the new admin/mod interface.

EDIT: Blah. Reopened. The ModCP page is done, but there's still no AdminCP page to actually promote non-admin and non-super-mod users to moderators.

Making a new post only to trigger a style issue in my subscriptions.

Updated so that permissions are calculated before the ping is saved, or emails are sent.

This allows us to avoid several queries on runtime (with some degrees of error), in the case mentioned earlier where the user is a moderator but might have an access mask -- so maybe they have can_delete permissions but don't have can_approve permissions. Such a case would have made unreviewed change notifications pointless and annoying for the moderator.

Additionally, some other items need to be moved around for more generic use, like the inline mod fill_items method, which gets the info for all parent nodes for a given item, and the inline mod test_permission method, which should just be replaced entirely by more extensive (and less semantic) use of tab permissions.

Moved all permissions to tab UI, and applied fill_items to its generic location. Wrapping up the admin interface for this now.

Completed for 4.0.0 Alpha 1.

Is this implemented for XF as well?

Yes, this should also be working under XenForo.