GPExpansion v1.2.0

This release lets the people responsible for a managed sign relocate it without destroying and rebuilding its GPExpansion state. Claim owners, active renters, sellers, buyers, global-sign creators, and unshared self-mailbox creators receive type-specific access, while staff can be granted separate permissions for moving somebody else's sign.

Subdivision handling is also more consistent. Active tenants can name the subdivision they rent, unnamed subdivisions inherit their nearest named parent's display name in PlaceholderAPI, and administrators can start evictions for rented subdivisions inside ownerless admin claims. Claim bans now eject an affected online player promptly instead of waiting for that player to move or interact.

Read the Behaviour Changes and Permissions sections before updating. The five controller sign-move permissions default to true, but every .other permission defaults to false and must be granted explicitly when staff should move signs they do not control.

No configuration keys or storage migrations were added. The Maven project version is now 1.2.0; version.config-version remains unchanged.

Managed Sign Moving

New two-step move workflow

Managed signs can now be moved with either command:

/claim movesign
/moveclaimsign

The workflow is deliberately interactive:

Run either command.
Right-click the existing GPExpansion sign.
Place another sign at the desired destination.
GPExpansion copies the managed sign onto the newly placed block and clears the old sign.

The placed destination sign is consumed normally from the player's inventory. Its material and orientation come from the sign the player placed; GPExpansion does not physically move or refund the original sign block. The old block remains in place with its front and back text cleared and its GPExpansion metadata removed.

The copied state includes:

all four lines on both sign sides;
text dye colour and glowing-text state on both sides;
the waxed state;
all persistent metadata owned by GPExpansion, including price, rental, item, mailbox, and claim associations.

Metadata owned by other plugins is not copied. Normal block-placement protection still applies to the destination, so the move workflow does not bypass GriefPrevention or another plugin cancelling BlockPlaceEvent.

Use /moveclaimsign cancel or /claim movesign cancel to stop an active move. A move also expires after two minutes and is discarded when the player disconnects.

Supported sign types and controllers

The source must be one of GPExpansion's managed rent, sell, mailbox, global, or self-mailbox signs. GPExpansion first determines whether the player controls that particular sign, then checks the corresponding permission.

Sign type	A controller is...	Controller permission	Move-another permission
Rent	The current claim owner or the active tenant	`griefprevention.sign.move.rent`	`griefprevention.sign.move.rent.other`
Sell	The current claim owner: the seller before purchase or buyer after transfer	`griefprevention.sign.move.sell`	`griefprevention.sign.move.sell.other`
Mailbox	The mailbox creator/seller, recorded owner/buyer, mailbox-claim owner, or parent-claim owner	`griefprevention.sign.move.mailbox`	`griefprevention.sign.move.mailbox.other`
Global	The player who created the global sign	`griefprevention.sign.move.global`	`griefprevention.sign.move.global.other`
Self mailbox	The recorded creator/owner, provided the mailbox has no shared users	`griefprevention.sign.move.self-mailbox`	`griefprevention.sign.move.self-mailbox.other`

Controller permissions default to true. The five .other permissions default to false.

Authorization is checked when the source is selected and again when the destination is processed. In particular, a renter must still have an active rental at completion time. An expired or former tenant does not keep control merely because they selected the sign earlier.

A shared self mailbox intentionally has no individual controller for moving purposes. Moving one requires the explicit griefprevention.sign.move.self-mailbox.other permission.

Stored locations remain synchronized

Completing a move updates GPExpansion's stored location where that sign type has one:

rent signs update the active rental's sign location;
mailbox and self-mailbox signs update the mailbox sign location;
a global claim spawn moves only when that spawn was the old sign block;
sell signs retain their claim and sale data directly on the destination sign and have no separate stored sign location to update.

Source clearing is scheduled at the source location and destination completion at the destination location. This keeps cross-region moves compatible with Folia's region scheduler.

Creator identity for new signs

New rent, sell, mailbox, self-mailbox, and global signs now store the creator UUID in GPExpansion-owned persistent data. This retains the seller or creator identity needed by the move authorization rules even when a mailbox or claim later changes hands.

Existing rent, sell, and mailbox signs continue to derive control from their active rental, claim, parent claim, and mailbox records. Legacy global signs predate creator metadata; on their first authorized move, GPExpansion treats the current claim owner as the safely inferable creator and adds the missing metadata.

Commands

`/claim info` aliases `/claiminfo`

/claim info [claimId] now runs the existing /claiminfo [claimId] implementation. It has the same output and permission checks:

griefprevention.claiminfo is required to use it;
griefprevention.claiminfo.other is still required to inspect a claim the player does not own.

The alias and its argument completion are available through GPExpansion's own /claim command and through the GP3D command addon/interceptor when GP3D owns the root command.

Sign-move command routing

movesign is similarly registered as a /claim subcommand and exposed through GP3D's command integration. The standalone /moveclaimsign command provides the same workflow for servers where another plugin's /claim routing makes a direct command more convenient.

Subdivision Fixes

Active tenants can name their rented subdivision

Running /claim name <name> while inside a rented subdivision no longer fails with the generic ownership message when the player is that subdivision's active tenant.

The resolver now walks to the deepest subdivision containing the player's full X/Y/Z location, checks the rental stored against that exact claim ID, and permits the rename when the renter UUID matches and the rental has not expired. griefprevention.claim.name is still required.

This exception applies only to naming. Renting a subdivision does not make the tenant its GriefPrevention owner and does not grant the other ownership-gated claim customization or management commands.

Unnamed subdivisions inherit a parent claim name

%gpx_currentclaim_claimname% now starts at the deepest subdivision containing the player. If that subdivision has no nonblank custom name, the placeholder walks upward and returns the nearest named ancestor. An explicit subdivision name always wins; an empty result is returned only when neither the subdivision nor any parent has a name.

%gpx_currentclaim_claimid% now uses the same deepest-claim resolution. Players inside a subdivision therefore receive that subdivision's ID rather than a parent ID returned by a broader GriefPrevention lookup.

Together, these changes let an unnamed rented area display the main claim's established label until its tenant gives the subdivision a more specific name.

Admin-claim subdivision evictions can start

Administrative claims deliberately have no owner UUID. /claim evict <player> previously passed the admin-claim authorization check, then failed later with Unable to determine claim owner when the eviction record needed an actor UUID.

When a player has griefprevention.adminclaims, GPExpansion now records that authorized administrator as the eviction actor for an ownerless admin claim. The existing griefprevention.evict requirement, standing/location validation, notice period, and renter notification behavior are unchanged.

Trust removal at eviction start and trust restoration after cancellation now target the actual rented subdivision instead of its top-level parent claim. This prevents an eviction in one subdivision from altering trust at the wrong claim level.

Claim Ban Enforcement

Adding a GPExpansion claim ban now schedules an enforcement check for the affected online player one entity tick later. If the player is currently inside the claim from which they were banned, the existing safe-ejection logic runs without waiting for movement, teleportation, interaction, or another incidental event.

Unbans do not eject anyone. The one-tick deferral lets the command or datastore operation finish its dismount and release work first and remains safe on both Paper and Folia.

Behaviour Changes

Claim owners and the eligible tenant, buyer, seller, or creator can move supported managed signs when they have the new type-specific permission. Those permissions are granted by default.
Players who do not control a sign require its exact .other permission. These permissions default to false; grant them explicitly to staff roles that should move other players' signs.
Moving consumes the destination sign and leaves the source sign block blank and unmanaged. It does not transfer the source block itself.
A rent-sign tenant is revalidated when the destination is processed and cannot complete a move after the rental expires.
Shared self-mailboxes are excluded from creator-level moving and require the .other permission.
New managed signs retain creator UUID metadata. A legacy global sign adopts the current claim owner as its creator on the first authorized move.
/claim name grants an active tenant a narrow exception for the exact rented subdivision; it does not broaden tenant ownership elsewhere.
%gpx_currentclaim_claimname% can now return a parent name inside an unnamed subdivision, and %gpx_currentclaim_claimid% now returns the deepest containing subdivision ID.
Starting an eviction in an ownerless admin claim records the authorized administrator as the actor instead of rejecting the operation.
Newly added claim bans can eject stationary online players after one entity tick.

Permissions

This release adds ten permission nodes:

griefprevention.sign.move.rent
griefprevention.sign.move.rent.other
griefprevention.sign.move.sell
griefprevention.sign.move.sell.other
griefprevention.sign.move.mailbox
griefprevention.sign.move.mailbox.other
griefprevention.sign.move.global
griefprevention.sign.move.global.other
griefprevention.sign.move.self-mailbox
griefprevention.sign.move.self-mailbox.other

Each base node defaults to true. Each .other node defaults to false. Existing permissions continue to govern claim info, naming, eviction, and admin-claim management.

Configuration and Language

No new configuration keys.
Twelve sign-move.* language keys provide selection, permission, success, cancellation, failure, and timeout messages.
New standalone command: /moveclaimsign [cancel].
New /claim subcommands: /claim info [claimId] and /claim movesign [cancel].
New persistent sign field: sign.creator. It is added as signs are created, with compatibility handling for older signs.
Maven artifact version: 1.2.0.

Compatibility

Built against GriefPrevention3D 18.2.7 and Paper 26.2. The move workflow uses Paper's sign-open event so copied text can replace the normal sign editor safely. Location-bound completion and clearing use GPExpansion's scheduler abstraction for Paper and Folia compatibility.

No storage migration is required. Existing rental, sale, mailbox, claim metadata, configuration, and language customizations retain their formats. Missing bundled language defaults continue to be available without overwriting customized values.

Verification

mvn clean package completed successfully and produced target/GPExpansion.jar.
The filtered paper-plugin.yml and bundled lang.yml were parsed successfully as YAML.
The project currently has no automated test sources, so Maven reported no tests to run.
The new commands, sign interaction workflow, cross-region movement, active-rental expiry check, admin-claim eviction path, tenant rename path, placeholder inheritance, and immediate online ban ejection still need live-server verification.

GPExpansion