Permissions FAQ

Discussion in 'Plugin Development' started by Dinnerbone, Jul 7, 2011.

Thread Status:
Not open for further replies.
  1. @Patrick Crespo – Pretty sure that when getPermission returns null it means the permission is not formally registered.

    @feildmaster – Um, it looks like getDefaultPermissions is what you want. Or, more specifically, since you want all registered permissions:

    Code (Text):
    1.  
    2. Set<Permission> allPermissions = pm.getDefaultPermissions(false);
    3. allPermissions.addAll(pm.getDefaultPermissions(true));
    4.  
     
  2. @Celtic Minstrel : I didn't get any values returned when I used that function.
     
  3. Offline

    Patrick Crespo

    @Celtic Minstrel - Right, but they were in the plugin.yml and don't get registered until after the onEnable() method. You can test this by putting a permission in plugin.yml, and monitoring an event (like a block break). In the BlockListener, get your permission that hasn't been "addPermission"'d, but is in your plugin.yml, and you'll see that it's not null. Then try and get the same permission during onEnable() and it will be null.

    That to me means the plugin.yml permissions do get registered, but not until after the plugin is enabled, which isn't the same behavior as other things in the plugin.yml (version, authors).
     
  4. @feildmaster – Then, either it's buggy or you truly don't have any permissions registered. I think the easiest way to check would be to add something to your permissions.yml and then see if that gets returned.

    @Patrick Crespo – Hm. That's interesting, and has the sound of a bug.
     
  5. Ah, maybe you didn't understand. I want all the registered permissions from ALL plugins. Not just the permissions registered in the single plugin. ;)

    EDIT: Maybe I'll just loop through all the plugins and get them individually... (Could be made MUCH easier if I could just have a function to get them all in the first place. =P)
     
  6. Well, from the JavaDoc it seems like that's what getDefaultPermissions is intended to do, so... I dunno.
     
  7. Offline

    Drat333

    Since the * wildcard was taken out, do I have to denote EVERY node? Or can I just denote a general parent? For example:

    W/ Permissions Plugin:

    -worldedit.*

    W/Bukkit Permissions:

    -worldedit.

    I REALLY do not want to write out EVERY permissions for plugins like WorldEdit. Is this way feasible, or is there another method that I could use?
     
  8. I believe worldedit.* should work. Whether wildcards of this sort work generally depends on the plugin they apply to.
     
  9. Offline

    samp20

    I'm not quite so sure. I think permissionsBukkit has some special temporary workaround. Otherwise you'll have to wait for WorldEdit to update to the latest version of Bukkit
     
  10. I recall hearing that WorldEdit already did that, but I could be mistaken.
     
  11. Offline

    Drat333

    Well, I was just using WorldEdit as an example, as its the first plugin that came to mind that has a ton of permissions. I use a load of others, like WorldGuard, FalseBook, the list goes on.
     
  12. Offline

    XZeenon

    How do I select what group players go into on first login?
     
  13. Depends on your group plugin. Go ask in their thread.
     
  14. Hey I was planning to add SuperPerms to my plugins, however one of them (BanRecipe) has it's permissions requested depending on the item id. This means when I come to define the permissions in plugin.yml the BanRecipe.* permission's children will have to be defined manually. This also means that added items though ModLoaderMP and (eventually) Spout will not be included within the children.

    Is there any way of making sure all sub nodes are included as true? Or do I just have to ask the server owners to make do and add their custom item manually?
     
  15. @Relick – Don't register the permissions for that in the plugin.yml; register them dynamically on startup. (You should probably also add a check to make sure it happens only in the first call of onEnable.) For example, if the permissions are of the form "banrecipe.itemname", this code would work:
    Code (Text):
    1.  
    2. HashMap<String, Boolean> allItems = new HashMap<String,Boolean>();
    3. for(Material material : Material.values()) {
    4.     allItems.put("banrecipe." + material.toLowerCase(), true);
    5.     // Or material.getId() if you prefer banrecipe.id type permissions
    6. }
    7. Permission perm = new Permission("banrecipe.*", "Permission for crafting all items", PermissionDefault.OP, allItems);
    8. Bukkit.getServer().getPluginManager().addPermission(perm);
    (The PermissionDefault part is optional; it ensures all ops will get the permission. Other options are TRUE, FALSE, and NOT_OP.)

    That won't work for Spout or ModLoaderMP items, though. I imagine that it would work for items registered through a Bukkit interface once it gets one for that, but not sure when that'll be. I think if you want to support custom items you should probably have a list of the custom item IDs in your config file and loop through that as well as the built-in ones from Material.
     
  16. Offline

    nick980324

  17. Ah thanks @Celtic Minstrel , that helps loads :). I didn't think to use that.

    Yeah, so I'll tell custom item owners to make do (or request it to be added). Using this I don't have to go through the item ids and add more every time there is a new minecraft update.
     
  18. Offline

    Zippy50

    Is there any possible way to have different permissions for different worlds? Say, if you wanted a creative world with give commands, but you also wanted a rp world with out the give commands.
     
  19. Offline

    rezznov

    how excatly would you convert them i need this for my srever
    thanks
     
  20. Well, it would be possible for you to read a list of additional items from the configuration file.
    You just remove all permissions when changing worlds and then add the new ones.
    That's a hard question to answer. If you've been using Permissions or GroupManager, you'll probably want to ask in the thread of whichever permissions plugin you like best (PermissionsBukkit, PermissionsEx, and bPermissions are the ones I know of). If not, you can create a rudimentary two-group setup using just permissions.yml.
     
  21. Offline

    rezznov

    thanks
     
  22. Offline

    Zippy50

    @Celtic Minstrel What exactly do you mean by "remove all permissions and then add the new ones"? Does that mean that I would have to manually remove the permissions and then manually add new ones every time I want to switch worlds or is there a setting that will do that? Please expound on that, because I am not understanding what you mean very well...
     
  23. As a plugin developer, that is exactly what you would have to do. As a server administrator, you just need to use a permissions plugin that has multiworld support.
     
  24. Offline

    Mr. X

    Hi
    i search a command for permissions, that like permissionsHandler.setGroup("Player1","Group1") exist exists such a command?
     
  25. Offline

    joselitoeu

    Can you please give me a sample of how i should configure this:
    -A group called "Owner" that has all permissions of all plugins, with only 1 member.
    -A group called "Admins" with 2 members and only a few permissions.(Use member1 and member2 as sample idk)

    And as i understood, the group called "default" has as members all players that aren't in a group. So:

    -The group "default" with basic permissions.

    I'm not asking to write much, but a least 2 samples of permissions in each group please. I downloaded the PermissionsBukkit v1.1, and i am having difficulty in setting it.
     
  26. @joselitoeu – This isn't the PermissionsBukkit thread.
     
  27. Offline

    ethanpitt

    I like the idea of the permission api bukkit implemented and really see its merits.
    no need to check for diff permission plugins and support them all, but ...

    I think bukkit should at least give us the option the implement our own system.
    so you could register a permission-plugin that handles the player.hasPermission() call.

    that way everybody would be happy, if no permission plugin overrides the .haspermission() call use the build in.
    else use the one provided.

    or maybe, use a event? like PlayerHasPermissionEvent.
     
  28. If I dont have any permission management plugins installed, and I set permission default to op, it works so that ops can use the thing (they have the permission), others cant (they dont have the permission)?

    So I could use the same player.hasPermission(), even if server admin "doesn't want permissions", but just the OP/non-OP?
     
  29. OK, here's a question about fairly non-standard usage of the API: is there a way to check that a given arbitrary username (who may or may not be online, and may not even be a real username) has a particular permission node, without resorting to plugin-specific API's?

    Background: I'm thinking about the CommandSigns plugin in particular, which allows commands to be run with elevated permissions. A virtual '&CommandSigns' user is checked for permissions so users can run commands they might not normally have access to. However, it has not been updated to use superperms, and the author (@Fluff) is currently MIA, so there's no guarantee it'll ever be updated.

    My interest in this is my own ScrollingMenuSign plugin, which can use the CommandSigns API to execute commands; it's looking more likely that I'll need to implement this permission-elevation functionality directly within SMS if CommandSigns is no longer being maintained. I'd really like to do it "properly", i.e. via the Bukkit API, and not have to deal with multiple permissions API's to make this sort of check. But is this sort of flexibility possible?
     
  30. Offline

    4am

    Currently, Bukkit does not persist Permissible objects, which means you cannot query offline users. I feel as though this is something that should be added, but there is discussion on exactly how this should be acomplished.
     
Thread Status:
Not open for further replies.

Share This Page