LuckPerms

LuckPerms

Mods
905k Downloads

primary_groups column in luckperms_players table has no purpose

lt-eburgess opened this issue ยท 4 comments

commented

Description

Background:

  • PostgreSQL 14 Database
  • LuckPerms v5.4.58
  • Paper version git-Paper-358 (MC: 1.19.3) (Implementing API version 1.19.3-R0.1-SNAPSHOT) (Git: f26e9cc)

Observed Behaviour:

  1. Updated the permissions column for a specific player in the luckperms_user_permissions table by changing their group.(groupname) permission.
  2. Executed /lp sync command in server console.
  3. Executing /lp user (username) info shows their Meta: primarygroup= is the group I assigned them.
  4. Executing SELECT * FROM luckperms_players; shows the primary_group column as different from what I previously assigned.

I also tried an UPDATE on a user's primary_group in the luckperms_players table, and after executing /lp sync it does not update a players group in game, nor does it update their group.(groupname) permission in the lp_user_permissions table.

Proposed Behaviour

If the primary_group column is to exist, both the luckperms_players.primary_group column and group.(groupname) permission in luckperms_user_permissions.permissions column should have a relation such that when the /lp sync command is executed, there should be a conflict resolution effort that redefines the luckperms_players.primary_group for that user.

Example workflow:

  1. /lp sync detects a difference between the group.(groupname) permission and the luckperms_players.primary_group column.
  2. Parse the group name from groupname in group.(groupname).
  3. Update luckperms_players.primarygroup for the specific player(s).

Extra Details

No response

commented

@lt-brlara

commented

The column is only used when the primary group calculation method is set to manual, and thus the data needs to be stored. Otherwise, the primary group is calculated at runtime, by default the highest weighted group a user inherits. As this data could be affected by contexts, storing it when the manual system isn't active would result in a ton of writes that serve no useful purpose for LP.

I'm going to assume you're attempting to automatically pull data from LP's database to use elsewhere, in which case I'd highly encourage you to instead hook into our API. The storage implementation is exactly that, implementation, and thus subject to change with no warning.

commented

I understand the getPrimaryGroup() pulls from the metadata, and that it inherits the highest weighted group a user inherits. What I'm saying is, the primary_group column in the luckperms_players table does not have a function pulling the primaryGroup that is used in metadata, thus deeming this column meaningless.

commented

Like _11 said, the column is used when the primary-group-calculation is set to manual (stored) (which it isn't by default), that will also make the switchprimarygroup command "work"; the other two options for that setting disregard the storage entry.

LuckPerms/bukkit/src/main/resources/config.yml

Lines 312 to 323 in 1bfbd27

# Controls how LuckPerms will determine a users "primary" group.
#
# - The meaning and influence of "primary groups" are explained in detail on the wiki.
# - The preferred approach is to let LuckPerms automatically determine a users primary group
# based on the relative weight of their parent groups.
#
# - Possible options:
# => stored use the value stored against the users record in the file/database
# => parents-by-weight just use the users most highly weighted parent
# => all-parents-by-weight same as above, but calculates based upon all parents inherited from
# both directly and indirectly
primary-group-calculation: parents-by-weight