Hello.

When I use p.playerHas(p, "plug.perm.here"); to check for permission, Vault reports the proper boolean however when I change this and reload the PEX file (Pex 1.19.1), Vault continues to report the same boolean value. A server reload/restart reloads the PEX file, however the same problem occurs (backwards now)

In English:

1. I have the node 'plug.perm.here' and I check this using Vault.
2. Vault allows me to do [whatever]
3. I remove this node from the PEX file
4. I reload PEX, /pex reload
5. Vault allows me to do [whatever] still
6. /reload
7. Vault denies [whatever]
8. Repeat steps 3-5, adding the node back
9. /reload
10. Vault allows me to do [whatever] again

Surely this is not intended, and therefore is a problem. Here is my permission check code:

//Checking plug.perm.here in the class I made named Vaulty
if (Vaulty.hasPermission(p, "perm.here")) {
    p.sendMessage("Permission OK");
}

public static boolean hasPermission(Player p, String perm) {
    if (p.isOp()) {
        return true;
    }

    if (permissionHandler != null) {
        if (permissionHandler.playerHas(p, "plug." + perm)) { return true; } else { return false; }
    } else {
        if (p.hasPermission(perm)) { return true; } else { return false; }
    }
}

Thank you!

Vault checks bukkit's internal permissions when supplied a player. So PEX is not correctly re-resolving permission on the player when it restarts, this has nothing to do with Vault, as vault does not manage permissions, it only checks them.

Hello Sleaker.

Thanks for your reply. I have just one more somewhat related question. Why were those new methods added yet the old methods not deprecated? Are they for different purposes (ie- one for PEX, etc. and one for SuperPerms?)

Thank you.

What methods?

Namely playerHas(...) and groupHas(...)

I had always used hasPermission(...) with no problem, however a user mentioned those methods here (#154) and it's unclear exactly what the difference - if any - is.

playerHas and has are just aliases for the same method in Vault. Using Vault's method for checking permissions allows you to be able to check offline permissions if you want, generally you should only use vault's method if you want to support P3 or need offline permission checks. otherwise continue to use player.hasPermission("perm"); - Vault shouldn't be used for normal permission use.

The hasPermission was probably just removed to prevent confusion with bukkit, and because it's a lot to type when you should know you're already dealing with permissions on a player with a simple has(player, perm) so the 'permission' was a bit unnecessary

Thanks for clarifying the method calls. Personally, I don't mind calling Vaulty.hasPermission(Player p, String s) as opposed to Vaulty.has(Player p, String s) because either way, I use a class to wrap up everything related to Vault. I have Vaulty.setupPermissions(), Vaulty.setupEconomy(), Vaulty.hasPermission(Player p, String s), and Vaulty.hasEnough(Player p, Integer b) all in one class. It's just my way of doing things. :)

I do however see what you mean about shortening it. I could declare a short PermissionHandler such as PermissionHandler ph = permissionProvider.getProvider() and then substitute Vaulty.hasPermission(Player p, String s) for ph.has(Player p, String s)

As for the problem with PEX not re-loading the permissions.yml file and/or Vault not being aware that PEX has done so: Is there anything I can do about it?

Example:

1. An example player named Player is given permission (PEX) to do something before the server is loaded.
   OR 1)
2. Player does '/cmd', which would print TRUE if they have permission and FALSE if not.
3. Vault says they're good to go because they have 'this.node'.
4. I open PEX's permissions.yml file and take their permission away.
5. /pex reload
6. Player does '/cmd', and still has permission.

The odd thing about this is that if I do a command to change their permission such as '/pex user Player remove this.node', the problem doesn't happen. It's as if when I do '/pex reload', it's not being caught somehow.

The problem is also nonexistent when the player relogs. So doing step 4 then 5 and the player relogging seems to fix it as well. As you said, this may be a problem with PEX itself, but I just want to clarify my issue so that all angles can be examined.

As always, thanks for your help.

unfortunately I'm fairly certain it's because PEX doesn't re-inject properly, or does so without updating it on the bukkit side. Something it does, when it reloads doesn't actually change the permissions to bukkit.