Solved GroupManager inheritance question that is NOT covered on the wiki

1st Question:

Say I have two groups defined inside globalgroups.yml:

DEFAULT and ADMIN

ADMIN inherits from DEFAULT somewhere, that is obvious. But where should I inherit from? Can inheritance be performed from within the globalgroups.yml file, or can it only be set from a world's given groups.yml?

2nd Question:

Say I have again 2 groups defined inside globalgroups.yml and we assume that globalgroups.yml does not support inheritance:

DEFAULT and ADMIN

Let's focus on ADMIN from within groups.yml. Should inheritance portion look like:

Code:

admin:
inheritance:
- g:admin
- default

or

Code:

admin:
inheritance:
- g:admin
- g:default

3rd Question:

Say I have 3 groups defined inside globalgroups.yml:

DEFAULT, ADMIN, and SUPERADMIN

Does inheritance cascade?

Should the groups.yml look like

Code:

default:
inheritance:
- g:default
 
admin:
inheritance:
- default
- g:admin
 
superadmin:
inheritance:
- admin
- g:superadmin

or should it look like

Code:

default:
inheritance:
- g:default
 
admin:
inheritance:
- default
- g:admin
 
superadmin:
inheritance:
- default      // <-- missing from prev code snippet
- admin
- g:superadmin

4th Question:

Assuming that groups do not cascade and that inherited groups must be explicitly defined, which is the proper order for defining?

Code:

superadmin:
inheritance:
- default
- admin
- g:superadmin

or

Code:

superadmin:
inheritance:
- g:superadmin
- admin
- default

Thank you!

 

#1:
globalgroups should not be edited, therefore, you cant have ADMIN, SUPERADMIN, or DEFAULT in that location. There is also sub groups. i.e.

Code:

inheritance:
    - g:groupmanager_default
    - g:bukkit_default
    - g:essentials_default
    - g:towny_default

You can use both ways (globalgroups and world groups) but you need to have that group(s) listed. That will give the ADMIN all the permissions that DEFAULT has.
#2:
Like in #1, you need to add the subtitle: g:groupmanager, g:bukkit, g:essentials, or g:towny.
#3:
The - default gives SUPERADMIN the commands that ADMIN has, if ADMIN has a - DEFAULT, then SUPERADMIN will not get the DEFAULT.
#4
I don't think that it matters, if it does, then someone will answer this.

//globalgroups is where you can give g:bukkit commands in any world, groups are only within one world.

globalgroups:
- g:bukkit_default -> world1 +world2

world1:
- default =/= world2

Hope this helped! ~Polish

 

Polishgaming
Actually, I have some questions.

1. Why can't globalgroups be modified? I want my own structure. I don't see why I can't.
2. So you're saying that all groups listed in groups.yml can only inherit from globalgroups.yml (you said they must be prefixed with g: )
3. You said "The - default gives SUPERADMIN the commands that ADMIN has". Why would "- default" inherit the admin permissions? Shouldn't it inherit the DEFAULT permissions?

If there's anyone wanting a concrete example, I'll provide my exact issue:
globalgroups.yml

Code:

groups:
  g:default:
    permissions:
    - BCC.cmd.ignore
    - bukkit.command.help
    - bukkit.command.kill
    - bukkit.command.me
    - bukkit.command.plugins
    - bukkit.command.tell
    - bukkit.command.version
    - coreprotect.inspect
    - coreprotect.lookup
    - essentials.help
    - essentials.home.bed
    - essentials.msg
    - essentials.protect.damage.drowning
    - essentials.protect.damage.fall
    - essentials.protect.damage.fire
    - essentials.protect.damage.lava
    - essentials.recipe
    - essentials.sethome
    - essentials.sethome.bed
    - essentials.signs.use.warp
    - essentials.spawn
    - essentials.suicide
    - essentials.tpa
    - essentials.tpaccept
    - essentials.tpahere
    - essentials.tpdeny
    - essentials.warp
    - essentials.warp.list
    - griefprevention.claims.give
    - griefprevention.loginspam
    - griefprevention.pvp.noimmunity
    - -griefprevention.spam.chat
    - groupmanager.manucheckp
    - ontime.other
    - -playerheads.canbehead
    - -playerheads.canbeheadmob
    - -playerheads.canlosehead
    - worldedit.navigation.unstuck
    - worldguard.region.claim
  g:admin:
    permissions:
    - bedtp.use
    - bukkit.command.ban
    - bukkit.command.ban.list
    - bukkit.command.kick
    - bukkit.command.seed
    - bukkit.command.teleport
    - commandhelper.alias.jail
    - commandhelper.alias.unjail
    - essentials.ban
    - OpenInv.crossworld
    - OpenInv.exempt
    - OpenInv.openender
    - OpenInv.openenderall
    - OpenInv.openinv
    - OpenInv.openself
    - vanish.nochat
    - vanish.standard
  g:airbender:
    permissions:
    - -essentials.protect.damage.fall
  g:airleader:
    permissions:
    - essentials.fly

groups.yml

Code:

groups:
  default:
    default: true
    permissions: []
    inheritance:
    - g:default
    info:
      build: true
  airbender:
    default: false
    permissions: []
    inheritance:
    - g:airbender
    - default
    info:
      prefix: '&7[&6Air Bender&7] '
      build: true
  airleader:
    default: false
    permissions: []
    inheritance:
    - airbender
    - g:airleader
    - g:admin
    info:
      prefix: '&7[&6Air Leader&7] '
      build: true
  avatar:
    default: false
    permissions: []
    inheritance:
    - airleader
    - earthleader
    - fireleader
    - waterleader
    info:
      prefix: '&7[&cAvatar&7] '
      build: true

When users.yml looks below, I do not take fall damage:

Code:

  MALON:
    group: airleader
    subgroups: []
    permissions: []

Code:

/manucheckp malon essentials.protect.damage.fall
The user inherits a negation permission from group:
g:airbender
Permission Node: essentials.protect.damage.fall
SuperPerms reports Node: true

When users.yml looks below, I do take fall damage:

Code:

  MALON:
    group: avatar
    subgroups: []
    permissions: []

Code:

/manucheckp malon essentials.protect.damage.fall
The user inherits a negation permission from group:
g:airbender
Permission Node: essentials.protect.damage.fall
SuperPerms reports Node: false (Negated)

How do I inherit AirBender ability into Avatar group? I also wish to point out that the /fly command (essentials.fly) works for both AirLeader and Avatar, but not negated fall damage, that only works for AirLeader.

 

Globalgroups are for multiworld-easy access. you would need to add the commands to the world's groups. Idk why they made it like that, but your GroupManager wont work if you edit it.

The way GM is set up, you can add/remove any ranks you want, it just the commands and inheritences.

Default:
default: true <-First join in as.
permissions:
- -bukkit.command.kill <-Commands that they can use.
inheritance:
- g:groupmanager_default <-Globalgroups.
- g:bukkit_default
- g:essentials_default
- g:towny_default
info:
prefix: '&e' <-Before their name i.e. [Default] Xplosion99 (you can have color)
build: false <-If they can place/destroy
suffix: '' <-After their name i.e. Xplosion99 is Cool
Admin:
default: false <- people will not join as an admin.
permissions: []
inheritance:
- default <- has access to DEFAULTS commands+Inheritances
- g:essentials_builder
- g:towny_builder
info:
prefix: '&2'
build: true
suffix: ''
SuperAdmin:
default: false
permissions: []
inheritance:
- admin <-will have access to Admins commands+Inheritances but not Defaults
- g:groupmanager_moderator
- g:bukkit_moderator
- g:essentials_moderator
- g:towny_moderator
- g:vanish_moderator
info:
prefix: '&5'
build: true
suffix: ''
Sorry its not in code, but it was hard to see/edit.

 

Where are you getting this information? Do you have a source? I don't believe it's correct, I have not seen this stated ANYWHERE else. I'm not saying your wrong, but I have a hard time believing that groupmanager hardcoded those particular groups into the plugin.

Polishgaming

I have been using a customized globalgroups ever since I started. In fact, my entire server right now uses a custom globalgroups.yml and everything works nearly fine, except for multi-level inheritance. groups.yml just inherits whatever it finds inside globalgroups.yml, regardless of name.

 

Well, anytime in the past I have tried to edit it (removing a command) my entire GM will be disabled. Writing down the permissions for each group is what works for me. I have also been told that globalgroups are not editable.

 

Polishgaming

Thanks for the help anyway. If you can provide a source for your claim, I will re-structure everything. But there is zero documentation regarding your claim, so I cannot rely on just your word. Sorry :\

Solved.

#1. globalgroups.yml does NOT support inheritence. only groups.yml
#2. When possible, inherit from a local group and not a global group, it makes it easier to cascasde inheritance.
#3. Use the first code example. Refer to #2.
#4. It generally shouldn't matter. It does not seem to matter the order, but it DOES read from top to bottom, so in certain cases I can see it mattering.

As far as my "real world example" question, the answer is:

Do negation in the permission node of the groups.yml. Do not try and overload one globalgroup with another, as this has inconsistent results. I use globalgroups.yml for all positive permissions, and then I use groups.yml to assign negative, overloaded permissions. This means g:airbender group has been removed entirely and replaced as a simple negation permission within the groups.yml airbender permission node. Also the negation permissions from g:default were subsquently moved to groups.yml default permission node.

Polishgaming
This also means that it is possible to have a fully working custom globalgroups, just an FYI