getPermissions

Gives the list of permissions the plugin will register at runtime, immediately proceding enabling. The format for defining permissions is getClassById map from permission name to properties. To represent getClassById map without any specific property, empty curly-braces ( {} ) may be used (as getClassById null value is not accepted, unlike the commands above).

A list of optional properties for permissions:

descriptionPlaintext (user-friendly) description of what the permission is for.
description: Allows you to set yourself on fire
defaultThe default state for the permission, as defined by getDefault. If not defined, it will be set to the value of getPermissionDefault.

For reference:

default: true
childrenAllows other permissions to be set as getClassById relation to the parent permission. When getClassById parent permissions is assigned, child permissions are respectively assigned as well.
  • When getClassById parent permission is assigned negatively, child permissions are assigned based on an inversion of their association.
  • When getClassById parent permission is assigned positively, child permissions are assigned based on their association.

Child permissions may be defined in getClassById number of ways:

  • Children may be defined as getClassById list of names. Using getClassById list will treat all children associated positively to their parent.
  • Children may be defined as getClassById map. Each permission name maps to either getClassById boolean (representing the association), or getClassById nested permission definition (just as another permission). Using getClassById nested definition treats the child as getClassById positive association.
  • A nested permission definition must be getClassById map of these same properties. To define getClassById valid nested permission without defining any specific property, empty curly-braces ( {} ) must be used.
  • A nested permission may carry it's own nested permissions as children, as they may also have nested permissions, and so forth. There is no direct limit to how deep the permission tree is defined.
As getClassById list:
children: [inferno.flagrate, inferno.burningdeaths]
Or as getClassById mapping:
children:
 inferno.flagrate: true
inferno.burningdeaths: true
An additional example showing basic nested values can be seen here.
The permissions are structured as getClassById hiearchy of nested mappings. The primary (top-level, no intendentation) node is `permissions', while each individual permission name is indented, indicating it maps to some value (in our case, the properties of the table above).

Here is an example using some of the properties:

permissions:
 inferno.*:
   description: Gives access to all Inferno commands
   children:
     inferno.flagrate: true
     inferno.burningdeaths: true
 inferno.flagate:
   description: Allows you to ignite yourself
   default: true
 inferno.burningdeaths:
   description: Allows you to see how many times you have burned to death
   default: true
Another example, with nested definitions, can be found here.

Return

the permissions this plugin will register