[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.

 

Hi there.
Running into some problems attempting to implement PermissionsBukkit +SuperPermsBridge on our server.
Basically there do not appear to be any restrictions - anybody can use anything (including /permissions), regardless of their Group.

I have paid very close attention to the syntax used in the example configs when structuring my own, and I believe they are both yml compliant.
Several lots of permissions are defined in permissions.yml, then called in config.yml for their respective Groups.

Here is permissions.yml:

Show Spoiler Hide Spoiler

Code:

commandbook.basic:
    description: Basic CommandBook permissions.
    children:
        commandbook.motd: true
        commandbook.rules: true
        commandbook.who: true
        commandbook.motd: true
        commandbook.time.check: true
        commandbook.say.me: true
        commandbook.msg: true
        commandbook.spawn: true
commandbook.donator:
    description: Donator CommandBook permissions.
    children:
        commandbook.kit.list: true
        commandbook.whereami: true
        commandbook.whereami.compass: true
        commandbook.whois: true
        commandbook.kit.kits.snowblock: true
        commandbook.kit.kits.slime: true
        commandbook.kit.kits.ice: true
commandbook.moderator:
    description: Moderator CommandBook permissions.
    children:
        commandbook.teleport: true
        commandbook.teleport.other: true
        commandbook.return: true
        commandbook.say: true
        commandbook.broadcast: true
        commandbook.time: false
        commandbook.setspawn: false
        commandbook.midi: false
        commandbook.intro: false
        commandbook.spawnmob: false
        commandbook.weather: false
        commandbook.give: false
        commandbook.more: false
        commandbook.rocket: false
        commandbook.barrage: false
        commandbook.shock: false
        commandbook.thor: false
travel.basic:
    description: Basic travel permissions.
    children:
        warpy.list: true
        warpy.warp: true
        myhome.home.basic.home: true
        myhome.home.basic.set: true
        myhome.home.basic.delete: true
        myhome.home.soc.others: true
        myhome.home.soc.list: true
        myhome.home.soc.invite: true
        myhome.home.soc.uninvite: true
        myhome.home.soc.public: true
        myhome.home.soc.private: true
travel.moderator:
    description: Moderator travel permissions.
    children:
        myhome.admin: true
carpet.vip:
    description: VIP carpet permissions.
    children:
        magiccarpet.mc: true
        magiccarpet.ml: true
mcbans.moderator:
    description: Moderator mcbans permissions.
    children:
        mcbans.kick: true
        mcbans.ban.temp: true
        mcbans.ban.view: true
        mcbans.lookup: true
        mcbans.mute.player: true
        mcbans.mute.all: true
        mcbans.mod: true
vanish.moderator:
    description: Moderator vanish permissions.
    children:
        vanish.vanish: true
        vanish.noaggromobs: true
        vanish.nopickup: true
        vanish.dont.hide: true
permissionsbukkit.moderator:
    description: Moderator permissionsbukkit permissions.
    children:
        permissions.player.setgroup: true
logblock.moderator:
    description: Moderator logblock permissions.
    children:
        logblock.tool: true
total.admin:
    description: Total Admin permissions.
    children:
        commandbook.*: true
        worldguard.*: true
        warpy.*: true
        myhome.*: true
        magiccarpet.*: true
        mcbans.*: true
        permissions.*: true
        worldedit.*: true
        vanish.*: true
        worldborder.*: true
        logblock.*: true

Here is config.yml:

Show Spoiler Hide Spoiler

Code:

groups:
    default:
        inheritance:
        permissions:
            commandbook.basic: true
            travel.basic: true
    regular:
        inheritance:
            - default
        permissions:
    donator:
        inheritance:
            - default
        permissions:
            commandbook.donator: true
    VIP:
        inheritance:
            - donator
        permissions:
            carpet.vip: true
    moderator:
        inheritance:
            - VIP
        permissions:
            commandbook.moderator: true
            travel.moderator: true
            mcbans.moderator: true
            vanish.moderator: true
            permissionsbukkit.moderator: true
            logblock.moderator: true
    seniorstaff:
        inheritance:
            - moderator
        permissions:
            total.admin: true
users:
    exampleuser:
        permissions:
        groups:
        - seniorstaff
    exampleuser2:
        permissions:
        groups:
        - default

Any advice would be greatly appreciated.

 

is there anyway to set prefixes to certain colors with permissionsbukkit? like have our admins purple and our mods green etc etc, any hepl would be greatly appriceated.

 

im using the example config and i don't have all permissions

iv been trying to get this working for about 2 days now, theres really no clear instructions on how to set this up. can someone please explain to me in full how to set this up.

 

got this today not sure of the actual severity

Code:

21:32:22 [SEVERE] Could not pass event PLAYER_QUIT to PermissionsBukkit

not sure why.... it happens from time to time though

 

@jesuswald - I don't see any problems in your configurations, but you should specify "default: false" for each of those entries in permissions.yml. I can't say for certain, but I believe it's just defaulting all of those nodes to every user since you aren't explicitly telling it to set to false.

@wildeebeast - Try mChat.

@br0ad456 - Without a working knowledge of which plugins you're trying to run, what build of craftbukkit you're using, which version of PermissionsBukkit (and/or SuperpermsBridge), and a server.log of any errors or an explanation of unexpected behavior, I can't really troubleshoot your problem.

@mrvertigo27 - That log message (by itself) tells me nothing. The remainder of the error should have appeared after it, which is what I need to solve it.

@Flatliner - I've done some more testing, and still can't duplicate this problem except with the zipped minecraft server that you sent me. I've tried every stable craftbukkit build from 1000+, with the latest PermissionsBukkit. Download the latest version of PermissionsBukkit again, and check it against this md5 sum: e9baccd35aa5ccb2a2b3cf7319e8a942

Also, check CraftBukkit 1046 against this md5: 488429f3a502cc2a9b4818aa8907f67d

I really can't figure this out. :(

 

There was nothing after it I promise you.... thats the odd part

lol i see what happened now hold on

Code:

21:32:22 [INFO] Connection reset
21:32:22 [INFO] MRVERTIGO27 lost connection: disconnect.endOfStream
21:32:22 [SEVERE] Could not pass event PLAYER_QUIT to PermissionsBukkit
java.lang.IllegalArgumentException: Given attachment is not part of Permissible
object org.bukkit.permissions.PermissibleBase@109d622c
        at org.bukkit.permissions.PermissibleBase.removeAttachment(PermissibleBa
se.java:147)
        at org.getspout.spout.player.SpoutCraftPlayer.removeAttachment(SpoutCraf
tPlayer.java:142)
        at com.platymuus.bukkit.permissions.PermissionsPlugin.unregisterPlayer(P
ermissionsPlugin.java:137)
        at com.platymuus.bukkit.permissions.PlayerListener.onPlayerQuit(PlayerLi
stener.java:24)
        at org.bukkit.plugin.java.JavaPluginLoader$2.execute(JavaPluginLoader.ja
va:251)
        at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.jav
a:58)
        at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.j
ava:332)
        at net.minecraft.server.ServerConfigurationManager.disconnect(ServerConf
igurationManager.java:146)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:608)
        at net.minecraft.server.NetworkManager.b(NetworkManager.java:231)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:85)
        at net.minecraft.server.NetworkListenThread.a(SourceFile:105)
        at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:451)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:361)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:422)
21:45:00 [INFO] [BBROTHER] Removed 0 records older than 1080h00m00s in 0h00m00s.

21:48:45 [INFO] MRVERTIGO27 [/127.0.0.1:58431] logged in with entity id 209143 a
t ([mrvertigo27] -543.5625, 70.0, -101.34375)
22:04:57 [INFO] Connection reset
22:04:57 [INFO] MRVERTIGO27 lost connection: disconnect.endOfStream
22:06:40 [INFO] [BBROTHER] Removed 0 records older than 1080h00m00s in 0h00m00s.

>

 

@mrvertigo27 - I suggest updating to CraftBukkit 1046 and Spout 70+, as well as the latest build for Permissions Bukkit (see the original post). I believe that's an issue that has been solved already. If, however, you're already running these bleeding edge (or near) versions, toss me some version numbers so I can see what's happening.

 

Thank you very much for your reply, I will test that out!
Testing aside, I think that I might stick with Permissions 3 for a little while, as the idea of a default-on permissions system frightens the stuffing out of me.

 

I think that it's only defaulting them to on because you're defining them in permissions.yml. Again, I might be wrong (I don't know how bukkit actually handles the permissions.yml file). As for the plugins you're using, plugin developers can default any nodes they wish to true through their plugin.yml, so it could be a combination of factors.

 

@KarnEdge – I don't know if you've fixed the loops error with default inheriting itself, but if not, just remove the "- default" line for the default group; don't replace "default" with something else.

@KrimsonEagl – For permissions for the built-in op commands, check out DefaultPermissions in my signature; note that it only works for those op commands that aren't being overridden by some other plugin, though.

@xKYLERxx – There are numerous other plugins that handle prefixes and suffixes. As for the global '*', that is replicable with a little work on your part; it does require listing all the plugins you have installed that have permissions, though, as well as knowing which ones are using the bridge. Let me know if you'd like me to help you with this.

@Soulsinner – If you want ops to not have permissions for everything, you may need to explicitly set some permissions to false; furthermore, PermissionsBukkit cannot actually affect the permissions that an op gets. Instead you need to use permissions.yml. Let me know if you'd like me to help you with this.

@alexmack929 – Sort of, yeah. The bridge basically converts Permissions 3 requests for permissions into Bukkit API requests.

@ACStache & @br0ad456 – PermissionsBukkit does not use the permissions.yml file. It uses the config.yml in the PermissionsBukkit folder (which is in your plugins folder). If it's not there, just go ahead and create it, but it should auto-generate the first time you start up the server.

The permissions.yml is used by the server itself to define additional permissions, usually ones that group other permissions. It has nothing to do with player groups.

@Flatliner – I suspect the inability to negate permissions is related to the way the superperms bridge handles wildcard nodes. I can't be sure though since I haven't taken a look at the code.

@sirmyllox – Permissions listed under the permissions: key rather than a world under the worlds: key are indeed global to all worlds.

@krinsdeath – Did you miss vildaberper's post at the bottom of the last page? It sounded like a possible clue to the PLAYER_QUIT problem, though I have no idea if he actually knows what he's talking about.

 

thanks krinsdeath

 

This just doesn't work. Using McMyadmin and it converted everything, but no mods recognize commands.


Broken. Reverting back...

 

I run this on McMyAdmin and it works fine the only thing I had to do is go to your users and groups tab, go to the settings tab, and reset to default. This must be done or some commands will not work. Then Re-add all the groups and permissions. The was an update For McMyadmin a few days ago that also involved replacing the .exe file.

 

@krinsdeath
You are awesome, I haven't noticed any breakages with the updates yet, any showstoppers I should be aware of other than the experimental fix for whiping chunks?

 

Readd all the groups? Why? Shouldn't need to......it converted everything and I even shut down the server then manually used the converter provided by the Bukkit team just to be sure it wasn't McMyAdmin doing something.

Shouldn't have to recreate everthing. That would be plain stupid (no offense to you, just saying McMyAdmin should convert it and appears to).

It just doesn't work.


I can disable permissionsBukkit, leaving only superperms and the old GroupManager enabled. This works just fine.....


It's something with permissionsBukkit. Could be mChat I suppose too as it seems to throw errors like "Could not pass event PLAYER_JOIN to mChat".


I'll be so glad when we have a stable permissions system in place that works. For now...I'm just going to not use permissionsBukkit.

 

Hello i need help with my permissions yml i get this error whenever i start my server, i use superperms bridge and the permissions jar in OP :

Code:

ERROR:

while scanning a simple key
  in "<unicode string>", line 16, column 13:
                worldedit.wand
                ^
could not found expected ':'
  in "<unicode string>", line 17, column 13:
                worldedit.selection.hpos
                ^

here is my permissions file, i need help!

Code:

users:
    D00med:
        permissions:
            cf.allowfly: true #CFBanner
        groups:
        - Admin
groups:
    Guest:
        permissions:
            permissions.build: false
    Admin:
        permissions:
            permissions.*: true
            superperms.*: true #Permissions
            permissions.*: true #PermissionsBukkit
            worldedit.wand
            worldedit.selection.hpos
            worldedit.selection.pos
            worldedit.superpickaxe
            worldedit.superpickaxe
            worldedit.replacenear
            worldedit.removenear
            worldedit.remove
            worldedit.reload
            worldedit.butcher
            worldedit.extinguish
            worldedit.thaw
            worldedit.generation.cylinder
            worldedit.generation.sphere
            cf.*: true #CFBanner
            cf.allowfly: true #CFBanner
            cf.allowcheat: true #CFBanner
            cf.command: true #CFBanner
        inheritance:
        - Regular
    Regular:
        permissions:
            permissions.build: true
        worlds:
            creative:
                coolplugin.item: true
        inheritance:
        -
messages:
    build: '&cYou do not have permission to build here.'

 

Yeah it's a bit of a puzzler.

Which permissions build is that checksum from? I've just been downloading builds of permissionsbukkit from build 21 to 15 on both of my home machines and 2 remote machines hosted in different data centers (in case my internet is dropping packets or somthing corrupting the dl's) and none of the builds have the checksum you mentioned for permissionsbukkit. Craftbukkit md5 is fine though.

@d00med Take your time when you're setting up your permissions. If you look at your config file, you'll see that you're missing :true off the end of your worldedit permissions. They should be like this:

Code:

worldedit.thaw: true

 

Hey, everything was working fine and then all of sudden, after a server restart, I get this​

http://pastebin.com/nJyW1fTc
here's my config file for permissionsbukkit
http://pastebin.com/h5z46Y4k
and the plugins I have installed

BorderGuard​

CraftbukkitUpToDate​

Worldedit​

Worldguard​

permissionsbukkit (duh)​

superpermsbridge ^^​

essentials​

essentialsSpawn​

spout​

MobDisguise​

simple prefix (couldn't get mchat to work)​

 

@krinsdeath
Ok, I even did it for you. Heres your new PlayerListener:
http://pastebin.com/r4xub6ZN

Would be great if you changed it, as I said; this is impossible to work with as a developer.
Its currently preventing me from using it as my plugin DefaultCommands blocks flight for some players, but not me. So when I fly for too long i cancel the kick event, which is causing PermissionsBukkit to throw an error for every PlayerMoveEvent i trigger (it seems), as the kick event is fired because Im flying while allow_flight is set to false.

 

Like with every other permissions plugin it's a mess to setup the permissions.
We need more configuration examples or even an tool to manage all that node gibberish.
People getting new into Permission-Systems are simply overwhelmed by all this....

 

Would it be possible for you to get this in Craftbukkituptodate? I could add it myself but it says tell the Author, so here I am Would make life easier for many people i'm sure for when updates come (I hope they do)

Also; If anyone wants a tool that makes editing permissions way easier than they could use VisualPermissions, it supports this. Just search it in the bukkit forums, also i think it would be good if a link to it was added somewhere in the info/instructions.

 

@SpaceManiac - Is it possible to run TheYeti Permissions and PermissionsBukkit paralleled?
Only one plugin needs PermissionsBukkit. Other plugins are still good with TheYeti Permissions. <--- Good old one ^^

 

@Mercury – Which is that one plugin? It should be possible to run them in parallel, but it's kind of silly.

 

how do you install it?

 

@vildaberper - I've incorporated the changes. With any of the latest dev versions you should not be getting tons of null pointers (in fact, you should see nothing), since it checks for null pointers prior to working with any attachments. I suggest you update.

@Mercury - It is possible, but not really recommended. You can support all of the "old" plugins by running SuperpermsBridge until they're updated for Superperms.

@kaise123 - I'll talk to Space about this, but the plugin is already in BukGet.

@xaviergmail - You've got your moderator group inheriting from your moderator group, which causes an infinite loop. Remove that, and it should be good.

@Flatliner - Build 18. 19-21 are just dependency changes, and shouldn't matter (or change anything).

 

Thank you, Ill update right away.

 

http://forums.bukkit.org/threads/fu...usic-notifications-and-more-1000.30294/page-4

 

that's compatible with Permissionsbukkit I do believe

 

Build 18 gives me this for the md5: aef4cac06df6648063e7faf274768e4d

which doesn't match the one you mentioned. That's on all my machines (local and remote), downloaded both with a browser and via wget/curl. Are you certain that you posted the right mdsum? Just it seems unlikely that I would get something different consistently every time, when I've downloaded on a couple of machines that don't even share anything in common (different networks etc).

 

@Flatliner - Very sorry, I md5'd a local build with some additional changes when I did that. >< The hash you're getting is right, in which case I'm completely confused.

After downloading these builds and doing the same thing as you (nothing but them), I cannot replicate this problem.

I can't fix what I can't see. :[

I have actually been doing this with the Spout client, but I tested (just now) with the vanilla client and received the same results, it works fine. I doubt that would be an issue, since this communication all occurs on the server, and not on the client.

Like I said, I can replicate the problem by using your zipped minecraft, but as soon as I download any build of PermissionsBukkit (18+), it fixes the problem. I don't understand why it would propagate to other builds. :(

Perhaps Space will be able to see something that I can't, because I'm stumped.

@CaptainPrice943 - You removed the "users" key, and so PermissionsBukkit doesn't know where to look. This is what it should look like:

Code:

users:
    CaptainPrice943:
        groups:
        - admin
groups:
    default:
        permissions:
            permissions.build: true
            essentials.spawn
    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.'

@ShAd0w2kXX - You need to update to the latest development build for per-world settings to work properly. You can find the latest build here.

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