Bukkit

Anyone who is using permission elevation needs to read this.

There are some significant changes to the way permission elevation is handled in v0.8 of SMS, and there will be a certain amount of migration required. Here's a summary of what has changed:

• Dropping the elevation_user setting (the fake &SMS user)
• Dropping fake user elevation commands. That's the /*command style, although signs using that command will continue to execute them but as if they were /@command instead
• Dropping Permissions 2.x/3.x support entirely. Permissions is a dead plugin, I won't be supporting it anymore. If you're still using it, you need to migrate to a superperms plugin (PermissionsEx, bPermissions, PermissionsBukkit...) or accept that SMS just won't work for you any more.
• Adding new elevation.nodes setting, which will be a list of permission nodes to be temporarily added (with value 'true') to any user who runs an elevated command.
• Adding new elevation.grant_op setting (default false) which if true will temporarily grant op status to any user who runs an elevated command. This would be needed if you need to run a command from any plugin which doesn't support superperms.
• Undecided about the @g:group restrictor. Checking for player groups means I have to hook into the API of every permissions plugin I want to support, which is ugly. But, I appreciate some commands may depend on this. Dropping @g would allow SMS to be completely permissions-provider-agnostic (as long as the permissions plugin in use implements superperms).
• Adding new @n:node, to check if the player has a specific permission node before running the command. This can be a replacement for @g - instead of checking if the player is in a group, check for a relevant permission node (which can be anything at all, even one you invent).

So why am I doing all this? A few reasons:

1. The fake-player model (/*command) as originally implement in CommandSigns was a very clever way of getting around the problem of running commands as a different user, but at the end of the day, it was a nasty hack - it hooked directly into craftbukkit.jar and used undocumentated/unstable calls, hence the need for a rebuild when the last RB of CraftBukkit came out. It was needed because Bukkit back then didn't provide the necessary support for permissions elevation. Now it's easy to dynamically add permissions to a player with the Bukkit API.
2. I'm ditching Permissions 2.x/3.x support forever (or unless & until a version of Permissions is released which implements superperms...).
3. I don't want to directly hook into the API of any permissions plugin if I can at all avoid it (hence the possible loss of the @g: restrictor). E.g. as far as I can see, zPermissions doesn't provide a published API for checking if a player is in a given group, so I don't support that. And I don't intend to hook into a new API every time a new superperms permissions provider is released. When we're asking if a player is in a group, what we really want to know is if a player has a certain permission. So why not just ask that directly with a @n: restrictor? (What will actually happen is that @g: and @n: will both be supported for one release, and then @g: will be dropped).

I appreciate some people may be inconvenienced by the change, but I believe it's necessary to streamline SMS and remove a lot of cruft that it's inherited. The migration is automatic: on the first run of v0.8, ScrollingMenuSign takes the list of nodes that the &SMS user has from your permissions config, and put them in elevation.nodes in the SMS config.yml. You will need to manually set elevation.grant_op to true if you need to run commands from any plugin which doesn't understand superperms.