Permissions aren't updating unless player relogs
Closed this issue ยท 10 comments
Hello All,
I have a command (/afk) which add a permission node to the player. It seems however this permission node isn't being recognized as added from our plugin until either:
LuckPerms v5.0.50 on all servers
Using PaperMC 42 on all servers and Waterfall 312 for Proxy.
- The Player relogs
- We run
/lp user {user} permission info
- We run
/lp networksync
We currently have 3 paper servers and one waterfall server. They are all connected using a MariaDB server and the message-service is set to SQL.
Here is some config entries you might find useful. They are the same on all 4 servers
sync-minutes: -1
messaging-service: sql
# If LuckPerms should automatically push updates after a change has been made with a command.
auto-push-updates: true
# If LuckPerms should push logging entries to connected servers via the messaging service.
push-log-entries: true
A quick note to this. It seems to only be an issue when using the API. Dispatching a command from any server works fine. I need to api to force an update as well.
Note in the config extract you posted above:
# If LuckPerms should automatically push updates after a change has been made with a command.
auto-push-updates: true
after a change has been made with a command
This doesn't automatically happen with the API - if you want to push your changes to other servers via the messaging service, you need to request this explicitly.
Something like this...
LuckPerms luckPerms = LuckPermsProvider.get();
public void addPermission(User user, String permission) {
Node node = PermissionNode.builder(permission).build();
user.data().add(node);
luckPerms.getUserManager().saveUser(user).thenRun(() -> {
luckPerms.getMessagingService().ifPresent(service -> {
service.pushUserUpdate(user);
});
});
}
public void addPermission(Group group, String permission) {
Node node = PermissionNode.builder(permission).build();
group.data().add(node);
luckPerms.getGroupManager().saveGroup(group).thenRun(() -> {
luckPerms.getMessagingService().ifPresent(MessagingService::pushUpdate);
});
}
I would suggest having a new API option to enable auto-push for the plugin as long as it isn't disabled in the config...
Something like this maybe?
// We made the entire ServiceProvider mumbo-jumbo here
LuckPerms api = provider.gerProvider();
/*
* Enable that LP should push updates, if nodes have been changed through the API.
* This would be ignored if you set "auto-push-updates" to false in the config,
*/
api.enableAutoPush(true);
It's intentionally this way - means you can make a number of changes (e.g. for multiple groups or users) and then push an update only once.
Why not just have a little timeout (like a second) before syncing automatically.
And if an automatic sync is not wanted it could either be cancled or a second overload of the save method that accepts a boolean to control that behavior.
Because quite frankly I can't think of a single reason why you wouldn't want to sync.
Also this reduces the complexity of API usage and also improves performance slightly as it reduces the syncs in most use cases.
Just my little opinion, but I would find it very strange to configure an api via config.
It's something a plugin developer needs to know while developing, so making it dynamic only adds to the problems.
What if one api developer expects it to autosync and another expects it not to? Would only lead to more confusion and make it more complex.
Explicit is better than implicit, especially in this case :)
I'm not saying there shouldn't be any explicit way. But I'm saying this API needs to be easier to use and also start making assumptions on the average use case.
It's not getting easier if there is some config for it, that's all I'm saying :)
And to be honest I haven't used the api before so I wouldn't know.
But to make it easier the most obvious way would be to make an additional argument for saveGroup.
Just an additional bool that controls if it should push after saving.
Also I'm not a fan of api's making assumptions that lead to a worse performance.
An API should be optimized for the average usage. And that is just a few added or removed permissions within a short time (average usage in regards to making changes). So having the auto sync trigger after a short timeout is appropriate.
I'm also against adding a config option like Andre suggest. And instead have it be controlled by the already existing config setting.