Add admin command to reset a player's generator data (#149)

[tastybento]

Closes #149

Feature

Adds /{admin} generator reset <player> — a way for admins to reset a single player's island generator data (unlocked, purchased and active generators) without wiping the whole database or deleting files.

Change

• Manager: StoneGeneratorManager.resetIslandData(island) removes the island's stored data and immediately recreates a fresh default data object, so the island keeps working (default generators re-applied, permission unlocks re-evaluated).
• Command: a new confirmable ResetCommand subcommand of GeneratorAdminCommand:
  • permission admin.stone-generator.reset
  • resolves the target player, checks they have an island in this world
  • asks for confirmation (it's destructive), then resets and reports success
  • player-name tab-completion
• Locale: new commands.admin.reset entries (parameters/description/confirmation) and a generator-data-reset success message.

Tests

• StoneGeneratorManagerTest.testResetIslandData — reset deletes the island's stored data.
• GeneratorAdminCommandTest: setup (permission/params/description), no-args → help, and target-with-no-island → error. Updated the help-listing test for the new subcommand.

Full suite: 106 tests pass.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds an admin-facing, confirmable command to reset a single player’s island generator data (unlocked/purchased/active generators) without wiping the whole database, by deleting the island’s stored generator data and immediately recreating defaults so the island keeps operating.

Changes:

• Added StoneGeneratorManager.resetIslandData(Island) to wipe an island’s generator data and reinitialize defaults.
• Added generator reset <player> as a new GeneratorAdminCommand subcommand with confirmation + tab completion.
• Added new locale strings for the command help/confirmation and a success message; added/updated unit tests for the new behavior and help listing.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/main/java/world/bentobox/magiccobblestonegenerator/managers/StoneGeneratorManager.java	Adds resetIslandData() that wipes stored island generator data and reinitializes defaults.
src/main/java/world/bentobox/magiccobblestonegenerator/commands/admin/GeneratorAdminCommand.java	Registers and implements the new confirmable reset admin subcommand (with tab completion).
src/main/resources/locales/en-US.yml	Adds admin reset command help/confirmation strings and a reset success message.
src/test/java/world/bentobox/magiccobblestonegenerator/managers/StoneGeneratorManagerTest.java	Adds a unit test covering reset behavior (deletes stored data).
src/test/java/world/bentobox/magiccobblestonegenerator/commands/admin/GeneratorAdminCommandTest.java	Adds tests for reset command setup and execution (help and no-island error); updates help listing assertions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tastybento]

Addressed the SonarCloud duplication and both review comments in a24e91d:

SonarCloud duplication (37-line block): the new ResetCommand was duplicating GeneratorWhyCommand — the identical player tab-completer and the target-UUID resolution/error handling. Extracted two shared static helpers in GeneratorAdminCommand — playerTabComplete(...) and resolveTargetUUID(...) — and switched both subcommands to use them, so the duplicated block is gone.

Review comments:

• resetIslandData on ownerless islands: it now recreates the data object via addIslandData, which works even when there's no owner (e.g. spawn islands) — validateIslandData returns early in that case. validateIslandData is still called for owned islands (to re-apply owner bundles/limits and re-evaluate unlocks). So the reset never deletes stored data without recreating it.
• Empty resolved player name: the reset command now falls back to the typed argument when getPlayers().getName(uuid) is empty, so the confirmation and success messages always show a name.

Full suite green (106 tests).

[tastybento]

Follow-up on the duplication: the shared static helpers only removed part of it — the identical execute preamble (arg check + UUID resolution) and tab-completion still matched between ResetCommand and GeneratorWhyCommand.

ed109d0 extracts an abstract PlayerTargetCommand base (extends ConfirmableCommand) that owns the argument validation, target-UUID resolution and player tab-completion, delegating to an abstract executeForTarget(user, name, uuid). Both GeneratorWhyCommand and ResetCommand now extend it and only implement setup() + their own executeForTarget, so the duplicated block is gone.

Note: Sonar's other reported pair (the two identical ImportCommand classes in GeneratorAdminCommand and GeneratorDatabaseCommand) is pre-existing duplication unrelated to this PR — happy to clean it up too if you'd like, but it felt out of scope for the reset command.

Full suite green (106 tests).

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

Duplication cleared — SonarCloud now reports 0.0% new duplicated lines and the Code Analysis check passes (commit 6dc1f06).

The last remaining block was the structurally identical constructor + setup() shared by GeneratorWhyCommand and ResetCommand (Sonar normalizes the differing string literals). Moved setup() into the PlayerTargetCommand base, deriving the permission and locale keys from the subcommand label, so the subcommands now only carry a constructor and their own executeForTarget.

Full suite green (106 tests).