Issue: Moderator permissions are not saved

I was able to successfully modify permissions for 2 moderators on your site, and changes were still there on second view. Even though both should pull the same permissions row anyway, this could be an issue with moderators that have 2 moderator rows for a given node. I think this is only possible for imports of super moderators, or if you explicitly create the same moderator twice without realizing it. I added a check in the DM for the next release to make it impossible to add the same moderator to the same area twice.

You'll need to remove the duplicate moderator entries (e.g. if a moderator has 'All areas' twice). Once there is only one row for each moderator, they might start pulling the permissions you expect.

As for the group "moderator permissions" being "Not Set", I found a bug in the importer while going through your logs that caused the values to be lost for this group during an import. However, this would not prevent you from being able to change them in the future.

I see. thanks.
But that does expose that the import process has issues with moderators. I also found that former moderators (we are talking about mods from many years ago) were imported even though they are no mods on my site at this time.

Users are imported as moderators if:
1. They are an admin in the source DB (mod all areas) OR
2. If source is vB, they are in a group with the super-mod bit enabled (mod all areas) OR
3. They have a row in the moderator table for all forums or a wiki forum

It is possible that you removed the old moderators from the Moderators list in the AdminCP (#3), but if the user was still a member of a super-mod usergroup, they will still be imported as a moderator.

Marking this as Fixed since I addressed two related issues as specified in my previous post.

None of the above 3 possibilities are true.
All users have been super-moderator years ago, but are not in the supermoderator usergroup nor the moderator list any more.

The 3 possibilities above are the 3 queries that are executed in order to import moderators. 1 query on the admin table, 1 query on the user table for usergroupid = super-mod-group-id (which due to a bug found in your logs returns 0 results in Beta 7 when called from XenForo), and 1 query on the moderator table.

The 4th possibility is when VaultWiki is installed on XenForo:
1 query on xf_moderator where is_super_moderator = 1

Apparently it was caused by the moderator table.