Permissions
Table of contents
- Overview
- Permission List
- Detailed Descriptions
- Permission Combinations
- Permission Management
- Best Practices
- Troubleshooting
This page documents all permissions used by EzBoost, including their purposes, default assignments, and examples.
Overview
EzBoost uses a hierarchical permission system to control access to different features. Permissions are checked in combination for certain actions.
Permission List
| Permission | Description | Default | Examples |
|---|---|---|---|
ezboost.use | Allows basic use of boost commands and GUI | Players | /boost, /boost speed |
ezboost.top | Allows viewing the boost top leaderboard | Players | /boosttop |
ezboost.admin | Grants access to admin commands | OPs | /ezboost create |
ezboost.reload | Allows reloading the plugin configuration | OPs | /ezboost reload |
ezboost.give | Allows giving boost tokens to players | OPs | /ezboost give player speed |
ezboost.cooldown.bypass | Bypasses boost cooldowns | OPs | Activate boosts without waiting |
ezboost.boost.<key> | Per-boost permission for specific boosts | Players | ezboost.boost.speed, ezboost.boost.jump |
Detailed Descriptions
ezboost.use
- Purpose: Grants access to player-facing boost functionality
- Required for: Opening the boosts GUI, activating boosts via commands
- Default: All players
- Note: This is a base permission that must be combined with specific boost permissions
ezboost.admin
- Purpose: Allows access to administrative features
- Required for: Opening the admin GUI to create/manage boosts
- Default: OPs (server operators)
- Note: This permission is checked for admin commands only
ezboost.reload
- Purpose: Permits reloading of plugin configuration
- Required for: Using
/ezboost reloadcommand - Default: OPs
- Note: Useful for administrators who need to reload config without full admin access
ezboost.give
- Purpose: Allows distributing boost tokens
- Required for: Giving boost token items to players
- Default: OPs
- Note: Useful for moderators or shop plugins
ezboost.cooldown.bypass
- Purpose: Ignores cooldown restrictions
- Required for: Activating boosts without waiting for cooldowns
- Default: OPs
- Note: Should be given sparingly to prevent abuse
ezboost.boost.<key>
- Purpose: Controls access to individual boosts
- Required for: Activating specific boosts
- Default: All players
- Examples:
ezboost.boost.speed- Access to speed boostezboost.boost.jump- Access to jump boostezboost.boost.strength- Access to strength boost
- Note: The
<key>corresponds to the boost key defined inboosts.yml
Permission Combinations
To activate a boost, players need:
ezboost.use(base permission)ezboost.boost.<key>(specific boost permission)
Example: To allow a player to use the speed boost:
ezboost.use
ezboost.boost.speed
Permission Management
Using LuckPerms (Recommended)
# Grant base permission
lp user <player> permission set ezboost.use true
# Grant specific boost permission
lp user <player> permission set ezboost.boost.speed true
# Grant admin access
lp user <admin> permission set ezboost.admin true
Using PermissionsEx
groups:
default:
permissions:
- ezboost.use
- ezboost.boost.*
admin:
permissions:
- ezboost.admin
- ezboost.reload
- ezboost.give
- ezboost.cooldown.bypass
Using GroupManager
groups:
Default:
permissions:
- ezboost.use
- 'ezboost.boost.*'
Admin:
permissions:
- ezboost.admin
- ezboost.reload
- ezboost.give
- ezboost.cooldown.bypass
Best Practices
- Grant base permissions broadly: Most players should have
ezboost.use - Restrict specific boosts: Use
ezboost.boost.<key>to control premium boosts - Limit admin permissions: Only trusted staff should have
ezboost.admin - Use wildcards carefully:
ezboost.boost.*gives access to all boosts - Test permissions: Use
/boostto verify GUI shows correct boosts
Troubleshooting
- GUI not showing boosts: Check
ezboost.useand specificezboost.boost.<key>permissions - Command denied: Verify appropriate admin permissions
- Cooldowns not working: Check
ezboost.cooldown.bypassfor staff