# Review the command privileges in a VotingPlugin reward

A reward command can run with more authority than the player who earned it. A typo or overly broad permission command can therefore affect the whole server. Review the exact command and substituted player before enabling a new reward for real votes.

## Before you change settings

Make a copy of the specific reward definition and identify where it is referenced. VotingPlugin supports inline sections and reusable files; editing a shared file can change several sites or milestones. Use a harmless message reward for the first wiring check.

## Follow the request through the plugin

1. Locate the active definition rather than generated files under `Rewards/DirectlyDefined`. The maintainer advises editing the original inline configuration, since generated queue files are not the source of truth.
2. Check whether each action executes from the console or a player context using the installed version’s reward reference. Use the target player placeholder only where supported; do not assume every output path expands PlaceholderAPI.
3. Review the substituted command for scope. Prefer a small item, currency or cosmetic action over operator access or a broad permission grant. Remove ambiguous commands that could target everyone when an argument is absent.
4. Test the harmless definition with an ordinary account, then introduce one reviewed action at a time. Check both online processing and a controlled offline delivery if that reward can be queued.

## Confirm the intended result

The intended player should receive only the configured benefit and no new administrative access. Confirm a second player’s balance, permissions and inventory remain unchanged. If several sites share a reward file, test one representative path from each affected caller.

## If the test fails

A file-based reward begins with its reward keys rather than an unnecessary extra wrapper. An inline section and a file reference have different structure, so preserve the documented format. A message working does not prove a command ran with the expected context.

Restore the copied source definition and disable only the new reward action if its scope is wrong. Preserve vote totals and queued evidence. If authority was accidentally granted, remove that specific grant and review logs before resuming the reward.

## Sources and related help

- [VotingPlugin maintainer reference 1](https://wiki-backup.bencodez.com/VotingPlugin/Rewards/)
- [VotingPlugin maintainer reference 2](https://wiki-backup.bencodez.com/VotingPlugin/Reward-File/)
- [Create and test Minecraft vote rewards with VotingPlugin](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/create-and-test-minecraft-vote-rewards-with-votingplugin)