Description

Changing the usergroup manually through the database, you expect to change the primary group in the players table
However, this is not the case you have to change the player record in permissions.permission from group.{old} to group.{new}
Changing the Primary Group will not change anything in the server when you obtain the info through /lp user {name} info

This will change whenever you update permissions.permission

Proposed behaviour

Either the usage so the primary_group definition in the players table will be used.

Remove the primary_group in the players table and only stick with user_permission table

Or better: use the normalisation default with a one to many table for groups as is:
user_groups
uuid | group | primary {true/false} | world {global/specific}

Behaviour in the plugin:

• User joins:
• Database is queried using the uuid
• All global groups are obtained including the current world

On world change: Obtain the groups for that specific world (lowers the amount of memory usage - as less data is kept in it's memory)

Reason of report:

It enables a create support to monetize servers by changing an usergroup for E.G to VIP or create your own management panel and change values in the db.

Also by editing the DB you would be able to link a discord bot to the database and change values if the user his/her (roles) changes by pushing it to the DB so the MC server automatically is updated.

###optimalisation:
Also using the normalization form will optimise the plugin (application) as there is less data to be obtained.

An player contains a uuid (unique user id)
Which means we can hold this as primary key (the row identifier) | {additional info}

A group is now only consistent out of a name. Maybe add the data related to a group to this table instead?
Such as: title, weight etc.etc.
The group name is unique so we can index this one as well as prinary key.
Then we get to the group based permissions:
Name | permission | value | context

Doing so we only need to obtain the permissions and values when the name and context is met.

Then we have a table user_groups (fixing many to many relations)
Here we hold the uuid | group | world {global/world} | primary group {true false}

To be specific by the amount of times the group is saved I rather see an AI primary key id on group to take less bits after all.

Now everything is linked to eachother with a minimum data usage, and thus lesser data to look up and thus lesser data to be stored in the memory. The ram usage would be slightly lower but also the amount of issues are lower as you simply can't have nulled values (you can't delete a user if it still has groups linked to it {if you use foreign keys})

Check what https://luckperms.net/wiki/Configuration#primary-group-calculation is set to in your config. ;)