GriefPrevention3D v18.3.4

Wiki: https://github.com/castledking/GriefPrevention3D/wiki

Overview

This maintenance release restores GriefPrevention's upstream manage-trust behavior. Players with manage trust may once again grant normal trust or manage trust to another player, and manage trust once again includes every lower interaction permission.

GP3D v18.3.0 separated manage trust from build, container, and access trust. It also restricted a manager to granting only permissions they separately held themselves, while granting manage trust was reserved for the claim owner. Together, those rules produced two confusing failures:

• a manager could grant container trust in some cases, but /trust <player> appeared to do nothing;
• /managetrust <player> appeared to do nothing unless the command sender owned the claim.

Both restrictions are removed in v18.3.4. Holding manage trust is now the complete authorization needed to manage the claim's grantable trust list, matching upstream GriefPrevention.

Manage trust is hierarchical again

The effective trust hierarchy is restored to:

Owner/Edit
  -> Manage
    -> Build
      -> Container
        -> Access
          -> Neighbor

A manager can therefore build, use containers, and access the claim without needing a second trust entry. Manage trust still does not grant owner-only Edit permission: managers cannot resize, delete, transfer, or otherwise perform actions reserved for the claim owner merely because they can manage trust.

The hierarchy is applied consistently by the Bukkit claim implementation and the shared trust model used by Fabric. Player UUIDs, public, and trusted permission-node identifiers all follow the same ordering when their effective permission is evaluated.

Managers can delegate trust

Trust commands now require the sender to hold Manage permission on the selected or current claim. There is no additional requirement that the sender personally hold the level being granted, and granting manage trust is no longer owner-only.

A manager may use:

• /accesstrust <player>;
• /containertrust <player>;
• /trust <player>; and
• /managetrust <player>.

This also applies when the commands are routed through GP3D's unified claim command interfaces. The separate administrative gate for granting trust to arbitrary permission nodes remains in place: /permissiontrust still requires griefprevention.permissiontrust.

Relationship to the owner-side trust-loss report

The clarification that the command sender owns the claim means the delegation restriction fixed in this release did not block that sender: claim owners already satisfied every grant check. The reported sequence is nevertheless consistent with the separate v18.3.1 storage bug. At that time a claim could store only one trust value per player. An owner could successfully give Linkondorf normal trust and then give him manage trust, but the second command replaced the first entry. Loading the claim applied Managers last and could repeat the overwrite. Because manage trust did not include interaction rights in v18.3.1, Linkondorf then appeared to have lost all useful permissions.

There is also an important command-name difference between those releases:

• In v18.3.1, /permissiontrust Linkondorf was an alias for granting player manage trust and could trigger the one-slot overwrite.
• Since v18.3.2, player manage trust is /managetrust Linkondorf. /permissiontrust <permission> <access|container|build|manage> now targets a permission node, so /permissiontrust Linkondorf is not a valid player-trust command.

v18.3.2 already fixed the destructive part by storing manage and interaction trust independently. v18.3.4 keeps that safer storage model while restoring the upstream hierarchy:

• granting manage trust does not overwrite an explicit build, container, or access grant;
• granting normal trust does not remove manage trust;
• both tracks survive claim loading and saving; and
• a surviving manager entry now provides lower interaction permissions by itself.

This means an existing player still listed under Managers regains build, container, and access without a claim-data migration. If old server versions removed both entries entirely, the claim owner must trust the player again. If a player should retain a particular interaction level after their manage trust is later removed, the owner should also grant that interaction level explicitly; the independent entry remains stored separately from manager status.

Subdivision scope can look like disappearing trust

Trust granted directly in a subdivision applies inside that subdivision and its inheriting descendants; it does not grant the same permission in the surrounding parent claim. With a 3D subdivision, moving above or below its Y bounds can therefore make working trust appear to vanish even though the subdivision entry is still present.

An untrusted parent does not asynchronously erase a direct subdivision grant. GP3D checks explicit trust on the current subdivision before consulting its parent, so the direct grant wins while the player remains inside that subdivision. A later /untrust performed on the parent can deliberately propagate removal into children which inherit its permissions, but there is no timer which clears a child grant merely because the parent lacks trust.

If /trust Linkondorf still appears ineffective after upgrading, confirm that the owner and Linkondorf are testing the same claim and vertical layer, that no old golden-shovel claim-selection session is targeting a different subdivision, and that /trustlist is being read from that exact claim.

Upgrade notes

• No configuration changes are required.
• No permission nodes, commands, aliases, or message keys were added.
• No claim-data migration or automatic claim rewrite is required.
• Existing Managers entries immediately receive the restored lower permissions.
• The independent storage introduced in v18.3.2 remains in place; this release changes effective permission evaluation and command authorization, not the on-disk claim format.
• /untrust <player> continues to remove both manage and interaction trust.

Verification

New command-level regression tests cover the upstream manager-delegation cases with a manager standing inside another player's claim. They verify that /trust Linkondorf records Build trust and that /managetrust Linkondorf records Manage trust. A separate owner-path test grants Build and then Manage to the same player and verifies that both entries remain. Hierarchy tests verify that Manage grants Build, Container, and Access while owner-only Edit remains denied.

The existing real flat-file round-trip test verifies that a player listed under both Builders and Managers retains both entries after a Paper load and save. Fabric evaluator and repository tests cover the same hierarchy for UUID and permission-node trust while retaining the explicit interaction grant alongside manager status.

The full ./gradlew check pipeline passes: 439 tests, 0 failures, 0 errors — 250 in the Bukkit plugin, 136 in the shared core, 51 on the Fabric platform, and 2 in the Fabric bootstrap. This also includes the universal JAR audit, Java 8 legacy class loading, shaded-core isolation, and the Fabric boot smoke test against the generated universal JAR.

Files Changed

 M gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustLevel.java
 M gp3d-core/src/main/java/com/griefprevention/claims/ClaimTrustSnapshot.java
 M gp3d-core/src/test/java/com/griefprevention/claims/ClaimTrustLevelTest.java
 M gp3d-core/src/test/java/com/griefprevention/claims/ClaimTrustSnapshotTest.java
 M gradle.properties
 M platforms/fabric-1.21.11/src/test/java/com/griefprevention/fabric/FabricClaimRepositoryTrustTest.java
 M platforms/fabric-1.21.11/src/test/java/com/griefprevention/fabric/FabricClaimTrustEvaluatorTest.java
 M pom.xml
 M src/main/java/me/ryanhamshire/GriefPrevention/Claim.java
 M src/main/java/me/ryanhamshire/GriefPrevention/ClaimPermission.java
 M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java
 M src/test/java/me/ryanhamshire/GriefPrevention/ClaimPermissionTest.java
 M src/test/java/me/ryanhamshire/GriefPrevention/TrustCommandPermissionTest.java