Partial fix custom User Permission

Affected version
2.0.0 RC 3

Active member

In ACP > User Permission
I can't see any option to revert "inherit" the permission of the user who have a custom User Permission. I tried to apply manually the permission to match the group permission that the user belongs so it will be removed automatically from that list but with no luck.

This leads to a conflict when installing a new addon with a setup file that has in it a $this-> applyGlobalPermission

The setep file permission as far as I can see applies to the groups only not the custom User Permission and if I try to change the permission of the group back and forth from Yes to No the custom User Permission stays always on what option is set to.

Am not sure if this a bug but I appreciate if you can guide how to remove custom User Permission.


Active member
Groups & permissions > Moderators
Adding a user with moderation permissions will add him to (Groups & permissions > User permissions)
Removing the moderation permission should remove the user permission but for some reasion it didn't.

I did a fresh install on my local and now the function works as it should. No idea what or where was the problem.


XenForo developer
Staff member
I'm afraid I'm not really following exactly what you're reporting.

Based on your last comment, I can only guess that you have some invalid permission entries (entries for a permission that doesn't exist). I would have to guess this is a legacy issue, though you might be able to confirm by looking in the DB directly.

Beyond that, I guess we'd need an extended explanation and ideally step by step reproduction steps.

Active member
I’m afraid I cannot reproduce the steps since it happened only once on a test installation where a user not been able to revoke his permissions from “Groups & permissions > User permissions” even he has no Moderator permissions “Groups & permissions > Moderator” or Administrator permissions “Groups & permissions > Administrators”. The only option I had is to do a fresh installation to get rid of this issue.

If it happened again I will make sure to report it in the correct way so you can follow.



Well-known member
@Mike same here. I already grant custom permissions to the user by selecting customize permissions, as described above. After all that I try to remove all his custom user permission, it's okay, but the problem is, his username still exist and showing up in list of users permission page. For example, if we give a custom user permission to a user, it wouldn't a problem after select "No Set" while using 1.5.x version and they've been removed from User permission page but for 2.0, it's problem.


Well-known member
#6 hi there, I think I have solved the problem like this...

First backup that table and run this query:

<snipped> don't do this
This will remove to all custom user permissions but don't forget, you need to give all these users who have custom permission a new permission (check usergroups too) level after run that query.

Note: I tested it now and works great and after remove a user permission, username(s) won't show up again.

Edit: I think seems like that there was a minor problem with cache listing remains from 1.5.x.
Last edited by a moderator:

Chris D

XenForo developer
Staff member
Can you please stop haphazardly truncating your tables...

You've just removed every single global permission entry for every single user group and user. This might currently only be working properly because the values are heavily cached. But once those caches are no longer valid, you'll likely find that none of your users or moderators have any permissions.

You might want to pre-empt this by going into Groups & permissions and setting all of the correct values...

Chris D

XenForo developer
Staff member
This is ultimately down to orphaned permission entries, such as where an old add-on didn't remove their set permissions on uninstall. We had already remedied this in XF2 as an add-on uninstallation should already remove the set permissions.

To handle the orphaned entry issue, we've expended our "Clean up permissions" tool under Admin > Tools > Rebuild caches so that it will detect and remove any orphaned messages.