Issue: Permissions override

Make sure the secondary usergroup is set to Not Set, or No. If a permission is set to Never, then the user will Never have permission regardless of any other usergroups. This is by design, because it is semantic with the implications of the word "Never", and it is consistent with the design of the "Never" level that is native to XenForo. This choice is available to vBulletin users because there is no reason not to make it available in both (in fact there would actually have been more development work required to remove it for vBulletin).

However, if the user is granted permission in a primary usergroup globally, and revoked that permission in a different usergroup only for a specific area, and the primary usergroup is not also customized for the same area, then there might be a bug where the custom permissions for a different group are overriding the global permissions when viewing that specific area. By design, custom permissions should only override global permissions for the same usergroup. If there is such a bug, I don't see a way that it would affect wiki functions that only rely on global permissions (like special pages).

Let me also stress that it doesn't matter whether the user has a group as its primary group or as a secondary group. A primary group doesn't override a secondary group. In vBulletin, all groups are given the same weight when it comes to permissions.

If the primary usergroup is the wiki moderators group, the user will not get permissions from this group, except for areas where the user has been designated as a moderator in the Permissions > Moderators panel. Thus, simply adding users to this group will not give them permissions. You must actually define them as a moderator. This is by design.

If the user has a user mask in Permissions > Access Masks, this will completely override their permissions from all of their user groups, except for settings with a "Not Set" value. In the case of "Not Set", it will defer to the calculated permissions based on the user's primary and secondary groups and the current area being viewed. This is by design.

The problem is while some users have 'X' group as their secondary usergroup, some have 'X' group as their primary, so setting some items to No/Not Set won't be ideal to some users.

An issue I'm having is having one usergroup having the ability to delete a users comments, but also has a secondary usergroup that can't. This causes the user not to be able to delete comments.
You can see this with the user 'Testing'. Feel free to change the password of it to access it.

The user's secondary group 'Donor' has "Can soft-delete wiki comments?" set to Never. As I said earlier, this will make the user Never able to do that, even if the user is in another group that is allowed to. Instead, Not Set (No) should be used if you want the permission to be inherited from a different group the user is part of.

In default vBulletin, there are only 2 choices for permissions: Yes and No. These have been sufficient for many years.
In VaultWiki, these same choices are available in: Yes and Not Set (No). We use the phrase of Not Set because it more adequately describes how permissions are calculated than vBulletin's phrasing did. If you find that both together are insufficient, then likewise you find vBulletin's own Yes/No system to be insufficient, as the functionality of these two choices are consistent with the design of the choices in vBulletin.

The calculation is actually very complicated, but in essence, on the global level, all the Yes values from all primary and secondary groups get added together. If there is anything that was not Yes, the user doesn't have permission for that.

Never was added later in the VaultWiki Betas because we added XenForo support, and XenForo has a third option "Never", which essentially bans the user from ever being able to get that permission, unless the "Never" value is removed. Thus the way "Never" works is consistent with the design of the platform it is inherited from.

I see you use "Never" quite a lot in your permissions. You will have to rethink this strategy, because the user will never get those permissions if they remain part of those groups.

Since the issue in the first post seems to definitely be tied to the use of Never, and Never is working as designed, I am closing this as Working as Designed.

Okay, but it looks like public joinable usergroups aren't listening to "Not Set (No)".
I have a primary usergroup (set as moderator of wiki) set to access all parts of the wiki, editing, commenting, etc. But if a usergroup has a joinable usergroup (as secondary usergroups) with all set to Not Set (No), the user with both groups wont be able to access the wiki/anything regarding the wiki. So it seems like in this case, it's sort of acting like "Never".
Interesting thing is if a user has a primary usergroup (wiki moderator) with several joinable usergroups, changing just one joinable usergroup's permission effects all usergroups, letting me able to view the wiki.

I pretty much have no more permissions set to "Never."

After much testing, it seems like setting a user as the Wiki Moderator as their Primary group is causing a lot of issues.
As it stands right now, if I make a usergroup with ONLY the group as the set wiki moderator, the user can't even access the wiki (All the permissions say "yes").
If I change the setting of wiki moderator to a different usergroup, the user would be able to view the wiki just fine.
If the wiki moderator group is set as a secondary usergroup, the user will be able to access the wiki.
Is this intended?

The user ONLY gains permissions from the wiki moderator group if they are defined as a moderator in Usergroups > Moderators, because the permissions only apply to the areas the user is allowed to moderate. This is by design.

So there is no point in adding a user directly to the wiki moderator group, as it won't do anything. VaultWiki automatically adds them to the group if they are added to Usergroups > Moderators.