[ADMN/DEV] PermissionsBukkit v2.0 - Official Default Groups Plugin [1.5.2-R1.0]

PermissionsBukkit - the Official Default Groups Plugin
Current Version: v2.0
Find PermissionsBukkit on BukkitDev!

If you are getting a specific error or cannot determine what is wrong with your permissions file, filing a ticket on BukkitDev will make me much more likely to respond to you; general questions are best to ask in this thread or on the forums on BukkitDev.

It's been a long time coming, but with the accomplishment of build 1000 Bukkit has finally accomplished a built-in Permissions system (codenamed Superperms). For more info on how they work, and how to integrate them with your plugin, see the official Permissions FAQ. Keep in mind that you should rarely, if ever, have to hook this plugin directly; instead keep things in the realm of checking player.hasPermission("yourplugin.node"). The FAQ thread has more info on how to use Superperms with things like chat prefixes/suffixes.

Features:

• Storage of users and groups in plugins/PermissionsBukkit/config.yml.
• Both users and groups can be assigned individual permissions and parent groups to inherit permissions from.
• Support for global and per-world permissions.
• Reload configuration from file with out reloading the plugin.
• Ability to check if a player has a specific permission node.
• Ability to dump all permissions a player has and the plugins that set them.
• Ability to print plugin, description, and default for a given permission node.
• Ability to modify the permissions of groups and users and the groups of a user in-game.
• Built-in antibuild via the "permissions.build" node (defaults to allowing anyone to build).
• A minimalistic bridge from Permissions 3.0 to Superperms is available as a separate plugin, which does not depend on PermissionsBukkit.

Command Usage:

Show Spoiler Hide Spoiler

PermissionsBukkit uses the command /permissions, with aliases /perms and /perm.

/permissions reload - reload the configuration from disk.
/permissions check <node> [player] - check if a player or the sender has a permission (any plugin).
/permissions info <node> - prints information on a specific permission.
/permissions dump [player] [page] - prints info about a player's (or the sender's) permissions.
/permissions setrank <player> <group> - set a player to be in a group with per-group permissions.
/permissions group - list group-related commands.
/permissions group list - list all groups.
/permissions group players <group> - list players in a group.
/permissions group setperm <group> <[world:]node> [true|false] - set a permission on a group.
/permissions group unsetperm <group> <[world:]node> - unset a permission on a group.
/permissions player - list player-related commands.
/permissions player groups <player> - list groups a player is in.
/permissions player setgroup <player> <group,...> - set a player to be in only the given groups.
/permissions player addgroup <player> <group> - add a player to a group.
/permissions player removegroup <player> <group> - remove a player from a group.
/permissions player setperm <player> <[world:]node> [true|false] - set a permission on a player.
/permissions player unsetperm <player> <[world:]node> - unset a permission on a player.

All commands have in-game help and are usable from the server console.

Configuration:

Show Spoiler Hide Spoiler

A permission node is a string like 'permissions.build', usually starting with the name of the plugin. Refer to a plugin's documentation for what permissions it cares about. Each node should be followed by true to grant that permission or false to revoke it, as in 'permissions.build: true'. Some plugins provide permission nodes that map to a group of permissions - for example, PermissionsBukkit has 'permissions.*', which automatically grants permissions for all PermissionsBukkit commands. You can also specify false for permissions of this type.

Users inherit permissions from the groups they are a part of. If a user is not specified here, or does not have a 'groups' node, they will be in the group 'default'. Permissions for individual users may also be specified by using a 'permissions' node with a list of permission nodes, which will override their group permissions. World permissions may be assigned to users with a 'worlds:' entry.

Groups can be assigned to players and all their permissions will also be assigned to those players. Groups can also inherit permissions from other groups. Like user permissions, groups may override the permissions of their parent group(s). Unlike users, groups do NOT automatically inherit from default. World permissions may be assigned to groups with a 'worlds:' entry.

The cannot-build message is configurable. If it is left blank, no message will be displayed to the player if PermissionsBukkit prevents them from building, digging, or interacting with a block. Use '&' characters to signify color codes.

An example configuration file might look like this:

Code:

users:
    ConspiracyWizard:
        permissions:
            permissions.example: true
        groups:
        - admin
groups:
    default:
        permissions:
            permissions.build: false
    admin:
        permissions:
            permissions.*: true
        inheritance:
        - user
    user:
        permissions:
            permissions.build: true
        worlds:
            creative:
                coolplugin.item: true
        inheritance:
        - default
messages:
    build: '&cYou do not have permission to build here.'

Permissions:

Show Spoiler Hide Spoiler

PermissionsBukkit checks for the following permission nodes:

• permissions.build - Allows a player to build. Defaults to true.
• permissions.help - Allows viewing of usage for /permissions.
• permissions.reload - Allows use of /permissions reload.
• permissions.check - Allows use of /permissions reload.
• permissions.info - Allows use of /permissions reload.
• permissions.dump - Allows use of /permissions reload.
• permissions.group.help - Allows viewing of usage for /permissions group.
• permissions.group.list - Allows use of /permissions group list.
• permissions.group.players - Allows use of /permissions group players.
• permissions.group.setperm - Allows use of /permissions group setperm.
• permissions.group.unsetperm - Allows use of /permissions group unsetperm.
• permissions.player.help - Allows viewing of usage for /permissions player
• permissions.player.groups - Allows use of /permissions player groups.
• permissions.player.setgroup - Allows use of /permissions player setgroup.
• permissions.player.addgroup - Allows use of /permissions player addgroup.
• permissions.player.removegroup - Allows use of /permissions player removegroup.
• permissions.player.setperm - Allows use of /permissions player addgroup.
• permissions.player.unsetperm - Allows use of /permissions player removegroup.

Also, the following parent nodes are provided for convenience:

• permissions.* - Maps to permissions.help, .reload, .check, .info, .dump, and to permissions.group.* and permissions.player.*. Defaults to op.
• permissions.group.* - Maps to permissions.group.help, .list, .players, .setperm, and .unsetperm.
• permissions.player.* - Maps to permissions.player.help, .groups, .setgroup, .addgroup, .removegroup, .setperm, and .unsetperm.

Frequently Asked Questions:

1. Where are my * nodes? (open) 1. Where are my * nodes? (close)

Bukkit's Superperms has no built-in concept of a global '*' node that automatically gives all permissions, which is intentional - a player can instead be given all permissions by being given 'op' status (that is, listed in ops.txt). Additionally, individual plugins define a parent node (which could be 'pluginname.*' or 'pluginname.all' or anything else) which maps to whatever subpermissions in that plugin the author desires.

An example is PermissionsBukkit, which provides three such permissions: 'permissions.group.*' for all /permissions group commands, 'permissions.player.*' for all /permissions player commands, and'permissions.*' for all /permissions commands (including permissions.group.* and permissions.player.*).

If you are using SuperpermsBridge, you can do something similar to '*' nodes for plugins which use Permissions 2.7/3.1 - see the next FAQ for more information.

2. How do I use SuperpermsBridge? (open) 2. How do I use SuperpermsBridge? (close)

SuperpermsBridge is kind of like FakePermissions for GroupManager or PermissionsBridge for PermissionsEx. Once it's installed, it pretends to be the Permissions plugin and converts any plugins that use Permissions 2.7 or Permissions 3.1 to use Superperms instead.

You can have PermissionsBukkit without SuperpermsBridge or SuperpermsBridge without PermissionsBukkit if you like, but both of these are limited in functionality. If you install SuperpermsBridge without PermissionsBukkit you will not be able to make use of PermissionsBukkit's groups feature or admin commands, and if you install PermissionsBukkit without SuperpermsBridge, plugins that have not updated to use Superperms directly will not function.

For plugins that use Permissions 2.7/3.1, you can use the special node 'superpermbridge.*' to give the equivalent of what used to be the '*' node for plugins that do not use Superperms directly. If you don't want to give the * node, you can also use the node 'superpermbridge.pluginname' to do the equivalent of what used to be the 'pluginname.*' node. Once again, these only apply to plugins that SuperpermsBridge handles and not to plugins using Superperms directly.

3. How do I use the root permissions.yml? (open) 3. How do I use the root permissions.yml? (close)

The file 'permissions.yml' in the root of your server can be used to set up custom parent permissions. Parent permissions are a single node that, when given to a player or group, automatically give all their children node. Here's a simple example:

Code:

server.basics:
    children:
        commandbook.motd: true
        commandbook.say: true
        commandbook.say.me: true
        commandbook.time: true

Now, if you give a player the node 'server.basics', they automatically get all the nodes listed here. Children may also say 'false' instead of 'true', in which case giving the parent will remove the child instead of giving it.

You can also specify a description if you like, which can be used by plugins to provide information on your node (such as PermissionsBukkit's /perm info command). If you want, you can also provide a default, which can be one of "true", "false", "op", or "notop". CraftBukkit will automatically assign everyone, no one (default), ops, or non-ops the children permissions based on the specified default. Without any plugin like PermissionsBukkit, you can use this defaults system as a limited way to assign people permissions. Here's a more complex example:

Code:

server.basics:
    description: Basic permissions for My Cool Server.
    default: true
    children:
        commandbook.motd: true
        commandbook.say: true
        commandbook.say.me: true
        commandbook.time: true
server.admin:
    description: Admin permissions for My Cool Server.
    default: op
    children:
        commandbook.broadcast: true
        commandbook.teleport: true
        commandbook.kick: true
        commandbook.ban: true

You can also define permissions without children, but this is of limited usefulness in permissions.yml (though is important in plugin.yml; see question #6)

4. How do I switch from (other Permissions plugin)? (open) 4. How do I switch from (other Permissions plugin)? (close)

Depends on the Permissions plugin! If you were using PEX's YAML backend, I have a converter done and available on the PermissionsBukkit Tools page. Also available on the tools page is an automatic converter for Essentials GroupManager users.yml and groups.yml files. Automatic converters for Permissions 2.7 and 3.x are on their way, but in the meantime you can still convert your configurations manually.

5. Where are prefixes and suffixes (or option nodes)? (open) 5. Where are prefixes and suffixes (or option nodes)? (close)

Bukkit Superperms has no built-in prefix/suffix settings or non-boolean permission nodes, so individual chat plugins will have to start supporting Superperms in order to make use of non-Permissions-plugin based prefixes and suffixes. Herochat, iChat, and Simple Suffix are all aware of the Superperms update, but in the meantime you can use mChat, which already supports Superperms.

Once you install mChat and configure the mchat.prefix, mchat.suffix, and mchat.group names in its configuration file (see the example), use PermissionsBukkit to give players or groups the permissions "mchat.prefix.admin", replacing "admin" with whatever node you configured. For example, with an mchat configuration that looks similar to this:

Code:

da-name-format: '+prefix+name&e'
date-format: HH:mm:ss
message-format: '+prefix+name&f: +message'
mchat:
    prefix:
        admin: '&4DtK [SO] &7 '
        sadmin: '&9DtK [SA] &7 '
        jadmin: '&aDtK [JA] &7  '
        member: '&cDtK [M] &7 '

You can assign players or groups the mchat.prefix.admin node to get the "SO" prefix, mchat.prefix.sadmin to get the "SA" prefix, and so on.

6. (Coders) How do I set up my plugin.yml? (open) 6. (Coders) How do I set up my plugin.yml? (close)

Take a look at this post in Dinnerbone's FAQ for an example. This is a lot like the setup of permissions.yml (see above), but you can also define non-parent permissions (just include description and default and leave out children).

7. Is PermissionsBukkit outdated? (open) 7. Is PermissionsBukkit outdated? (close)

No! PermissionsBukkit 2.0 was last updated for 1.3.1-R2.0, is verified to work on 1.4.7-R1.0, and is unlikely to break on future releases.

Downloads:
Current Version:

PermissionsBukkit v2.0 (jar) (details)
Old Versions:
PermissionsBukkit v1.6 (jar) (details)



Changelog:

Friday 7 September 2012 (2.0)

• Fixed a case-sensitivity issue with setting per-world permissions that could cause some permissions to fail to apply.
• Added /perm setrank <player> <group> subcommand (alias rank) with per-group permissions (permissions.setrank and permissions.setrank.<group>)
• Added plugin metrics via http://mcstats.org/plugin/PermissionsBukkitMCStats (disableable in plugins/PluginMetrics/config.yml)

Wednesday 29 February 2012 (1.6)

• Fixed some massive issues that were caused due to having uploaded a buggy, in-development version instead of 1.5.
• Note: If your configuration was messed up as a result of this issue, the new build should gradually correct it as needed.

Saturday 25 February 2012 (1.5b)

• Revamped to be compatible with R5.
• Fixed issues with permissions not carrying properly on world change.
• Many internal improvements for performance and stability.
• SuperpermsBridge: in honor of R5 removing deprecated code, SuperpermsBridge is officially gone!

Monday 18 July 2011 (1.1/1.2)

• Fix BukkitContrib incompatibility issues.
• Improved the output of the /perm check command.
• Fixed issues when 'users:' is not specified in the config file.
• Fixed the /permissions reload command.
• SuperpermsBridge: improve wildcard handling; in addition to 'superpermbridge.*' and 'superpermbridge.pluginname', now supported are 'superpermbridge.plugin.*', 'superpermbridge.plugin.subnode.*', and so on.

Monday 18 July 2011 (1.0/1.1)

• SuperpermsBridge: adding the special 'superpermbridge.*' and 'superpermbridge.pluginname' nodes (see #2 in the FAQ for details).

Sunday 17 July 2011 (1.0/1.0)

• Initial release of PermissionsBukkit v1.0 and SuperpermsBridge v1.0.

 

Doesthis work on the latest dev build for 1.8.1 ?

 

I'm noticing that the default craftbukkit permissions don't seem to work on latest dev build, they are requiring op.

 

whats this?When I try to convert my GM user and grp files from paste? Using the tools page

Fatal error: Uncaught exception 'InvalidArgumentException' with message 'Unable to parse string: Malformed inline YAML string ('&4General&1).' in /f5/wombatymuus/public/minecraft/permissions/sfYaml.php:100 Stack trace: #0 /f5/wombatymuus/public/minecraft/permissions/index.php(196): sfYaml::load('users:?? turbo...') #1 /f5/wombatymuus/public/minecraft/permissions/index.php(298): calculateResult('users:?? turbo...', 'GM') #2 {main} thrown in /f5/wombatymuus/public/minecraft/permissions/sfYaml.php on line 100

 

Needing some help here. First, how can I make first time users default to a group? Right now they join and aren't put into a group. And second, I'm having a bit of trouble with the config. I'm getting parse errors though nothing that I see in the .yml is wrong?

Console message: http://pastebin.com/NxJ4N17R

Groups: http://pastebin.com/mCCvDCym

Edit: I think what the above poster said's true, because no restrictions are being given out to any of my players.

 

fix 1.8.1 suport!!!

 

I wish this system worked. I wish developers would get together, fuse their perm plugins, and then immediately thereafter the plugin developers would update their plugins to use the new system. Unfortunately, I've been stuck where the only working system I can find is the crappy outdated 2.7 system.
PermEX fails, hard to use, plugins unsupportive
Bukkitperms fails, weird to use, hardly any plugins support it
perm3.0 fails plugins unsupportive
perm2.7= old as hell, but works.

 

@Derpkraft @TheDeclonedCrafter Pass your YAML files through http://yaml-online-parser.appspot.com/ and fix any issues, and get back to me.
@Fr0zenfr0g What's broken?
@Woolcity Pretty much every new plugin and a lot of old ones use the Bukkit system for permissions, which means they automatically support this, PEX, and a few other permission managers. 2.7 is great, but new plugins won't support it. If you have a specific issue, I'd be glad to help.

 

@SpaceManiac
After running through the parser, I get this:

Code:

ERROR:

while scanning a simple key
  in "<unicode string>", line 95, column 13:
                simpleprefix.op:true
                ^
could not found expected ':'
  in "<unicode string>", line 96, column 13:
                lwc.admin: true
                ^

But in the config, http://pastebin.com/H3LXwaEd, lines 95 and 96 are just like every other one.

 

@TheDeclonedCrafter You're missing a space after the ':' on line 95.

 

@SpaceManiac Silly me

---

Now to get prefixes to work...

 

yes. I was trying to get pex to work, originally. But my logblocks plugin wouldn't work with it. Are you familiar with teamviewer or would you be willing to take a look at my current configuration?

wait a minute. nvm. sorry. :/ you say that permissionsEX supports multiple types of permission systems though, right?
Does that mean you can use more than one at a time? (I'm doubtful, but still hopeful)

 

On 1.8.1 dev build 1130 using the "temporary" 1.2 version of PB, PermissionBukkit's own nodes returned false. Building did not work for non ops, and the /permission command returned with that I did not have permission to use that command both in game as op and in the server console. I switched to the latest ci build and that seemed to solve the problem.

 

Ok, I got my Config.yml for BukkitPerms straight to a point, just can manipulate build: true / false, multiverse ( using [ superpermbridge.multiverse.portal.access.Nether1: true
multiverse.portal.access.Nether1: true superpermbridge.multiverse.core.tp.self: true ) And Only still can I enter these worlds/ portal ] ) essentials ( untill I see updated plugins Im not bothering with changing unless it's the issue, though I haven't seen it become an issue yet, minus Group manager which got the chuck )

As for the Bukkit.yml and Perms.yml in the server root, in the Bukkit.yml under Permissions= Permission.yml ( default ) can I just use the BukkitPermissions.yml ? or do I need another Perm plugin?

 

For some odd, and sad reason, I still can't get this to work. Even when i'm default, I can build but I can't use the designated permissions that I gave the default rank. The server can't sense permissionsbukkit unless I have superpermsbridge in the plugins folder. I even ran it through the yaml parser and it yielded no errors. I'm confused. Please help

 

@SpaceManiac For me, what seems to be happening now, is that there is no actual default group. So when players join for their first time they aren't put into a group. My config: http://pastebin.com/NaUWRhp8. I was thinking maybe the first group was automatically set as the default one, though new players can build, and the first group, guests, cannot.

What am I missing here? I know Permissions had the "default: true/false" option for groups but I don't see anything similar with this.

One more question about nodes. If I don't give a group a node does it automatically deny them access to that node's command? Like if I were to do this:

Plugin A has three permission nodes. PluginA.God, PluginA.Heal, and PluginA.Tp.
Group 1 permissions:
PluginA.God: true
PluginA.Heal: true

PluginA.Tp is not listed. So is Group 1 allowed to use PluginA.Tp's command, or must I define it as false first?

 

Yes, I miss the Users.yml that would auto add usernames and throw in default, then I know what the hell was going on, Now Im more lost then a Unic in a sex shop...


Edited to add, that I also divided by zero and my world is made of creepers now.... And something keeps flashing in red text " Countdown Imminent, Please seek cover " *Shrug*

 

Hello everybody, i'm using Permission 3 and i would like to know how i can switch a player to an other group without using the ftp, just typing a command ? Because I didn't understand the command

 

What your looking for is /pr <Player name> parents add <group> and /pr <Player name> parents remove <group>

Also this isn't the area to post for Permissions help. That is now inactive.

Also i seem to be having problems? I can't access /permissions ingame with the permissions.* node of via server console? Is there a way to fix this as it's annoying doing /reload and having to go into FTP to change groups all the time.

 

/pr <Player name> parents add <group> and /pr <Player name> parents remove <group>
Is there a config help that lays it all out like a cheap whore? Come on, I want nitty gritty details to clear everything up.

 

Hello.
Is it possible to limit the perm node of setgroup/addgroup so that someone with a certain rank/group cannot promote someone else higher than their own rank? It was like that in the old Groupmanager and I apologize if this has been answered before, I did not find it.

 

@SpaceManiac Help with this please, especially on setting a default group

 

@Vittek – Sorry, it's not possible at this time with this plugin.

 

I have a problem

Code:

17:37:01 [SEVERE] Could not load 'plugins\PermissionsBukkit-1.2.jar' in folder '
plugins':
while scanning for the next token
found character         '\t' that cannot start any token
 in "<reader>", line 39, column 1:
        permissions:
    ^

        at org.yaml.snakeyaml.scanner.ScannerImpl.fetchMoreTokens(ScannerImpl.ja
va:360)
        at org.yaml.snakeyaml.scanner.ScannerImpl.checkToken(ScannerImpl.java:18
3)
        at org.yaml.snakeyaml.parser.ParserImpl$ParseBlockMappingValue.produce(P
arserImpl.java:592)
        at org.yaml.snakeyaml.parser.ParserImpl.peekEvent(ParserImpl.java:163)
        at org.yaml.snakeyaml.parser.ParserImpl.checkEvent(ParserImpl.java:148)
        at org.yaml.snakeyaml.composer.Composer.composeNode(Composer.java:132)
        at org.yaml.snakeyaml.composer.Composer.composeMappingNode(Composer.java
:230)
        at org.yaml.snakeyaml.composer.Composer.composeNode(Composer.java:160)
        at org.yaml.snakeyaml.composer.Composer.composeMappingNode(Composer.java
:230)
        at org.yaml.snakeyaml.composer.Composer.composeNode(Composer.java:160)
        at org.yaml.snakeyaml.composer.Composer.composeDocument(Composer.java:12
2)
        at org.yaml.snakeyaml.composer.Composer.getSingleNode(Composer.java:105)

        at org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseCons
tructor.java:124)
        at org.yaml.snakeyaml.Yaml.load(Yaml.java:264)
        at org.bukkit.util.config.Configuration.load(Configuration.java:82)
        at org.bukkit.plugin.java.JavaPlugin.initialize(JavaPlugin.java:157)
        at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.j
ava:175)
        at org.bukkit.plugin.SimplePluginManager.loadPlugin(SimplePluginManager.
java:213)
        at org.bukkit.plugin.SimplePluginManager.loadPlugins(SimplePluginManager
.java:136)
        at org.bukkit.craftbukkit.CraftServer.loadPlugins(CraftServer.java:138)
        at org.bukkit.craftbukkit.CraftServer.reload(CraftServer.java:408)
        at org.bukkit.Bukkit.reload(Bukkit.java:173)
        at org.bukkit.command.defaults.ReloadCommand.execute(ReloadCommand.java:
22)
        at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:16
3)
        at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:3
53)
        at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:3
49)
        at net.minecraft.server.MinecraftServer.b(MinecraftServer.java:499)
        at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:478)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:374)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:417)

Permissionsbukkit file
http://pastebin.com/AmjUxXFr

Heres the results from parser

Output

ERROR: while scanning for the next token found character '\t' that cannot start any token in "<unicode string>", line 39, column 1: permissions: ^

ok well i fixed the problem above.... but i got another

18:15:29 [INFO] Server permissions file permissions.yml is empty, ignoring it

Permissionsbukkit file
http://pastebin.com/AmjUxXFr

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Hi,
Since 1.8 and the latest bukkit, PermissionsBukkit has been crashing after the server is online for 3-4 hours. People can no longer access permissions required commands - factions etc.
Any ideas why?

 

Not an error.

 

@TheDeclonedCrafter - The default group needs to be named "default." Simply change your "Guest" to "default" and all will be well.

@undefinedarray - Replace all tabs with 2 or 4 spaces and run the file through the parser again.

@EnisThenis - I cannot say what the issue may be, but it is very unlikely that PermissionsBukkit is crashing, since it does next to nothing to influence the game. The most likely scenario is that some other plugin is wiping permissions attachments and causing the problem, and my best guess would be Spout. However, the 1.8 (craftbukkit 1100+) builds are experimental and still in development, and as a result I believe this behavior may be temporary. A fully tested and stable build will be released when the CraftBukkit build has stabilized.

 

Is per world inheritance possible? Such as:

Code:

groups:
    default:
        permissions:
            mchat.prefix.default: true
        world:
            survival:
                permissions.build: true
            creative:
                permissions.build: false
    user:
        permissions:
            mchat.prefix.default: false
            mchat.prefix.user: true
        world:
            survival:
                permissions.build: true
            inheritance:
            - default
            creative:
                permissions.build: true  

As you can see, i want just the survival world permissions to be inherited....

 

It dose this with out you adding any thing to the second group i use it for my creative map. i give the vip's the permission to build on the creative map the the rest of the groups get their permission from vip. you dont need to add any thing else as long as you have a main inheritance chain like default>player>admin already working.

 

In your specific case, normal inheritance should do what you want, since there's nothing to be inherited in other worlds or globally.

 

Hi sorry can you please tell me why this is not working...

Code:

groups:
    default:
        permissions:
            permissions.build: true
            DuckShop.use.*: true
            DuckShop.create.personal: true
            DuckShop.break.personal: true
    admin:
        permissions:
            permissions.*: true
        inheritance:
        - user
    user:
        permissions:
            permissions.build: true
            DuckShop.use.*: true
            DuckShop.create.personal: true
            DuckShop.break.personal: true
        inheritance:
        - default
users:
    tom1ahawk:
        permissions:
            permissions.*: true
        groups:
        - admin
    Kaymoswhite:
        permissions:
        groups:
        - user

Its becoming very frustrating