Permissions build:deny etc inherited by groups with build:allow

[GoogleCodeExporter]

***If you do not attach your Zones.txt, EpicZones config.yml, your
Permissions config.yml and the startup log of your server, Your issue will
not be accepted.***

What steps will reproduce the problem?
1. Typing /zone edit (name), then /zone perm (group) (action) (allow/deny)

In my case I have five groups :

New
Survivor
Builder
Moderator
Admin

New players cannot build or destroy anything, anywhere. So they do not need to 
be included in the permissions.

/zone edit test
/zone perm Survivor build deny
/zone perm Survivor destroy deny
/zone perm Survivor entry deny

/zone perm Builder build deny
/zone perm Builder destroy deny
/zone perm Builder entry allow

/zone perm Moderator build allow
/zone perm Moderator destroy allow
/zone perm Moderator entry allow

Admin has access to zones.admin and therefore can do anything to all zones.

What is the expected output? What do you see instead?

Expected: Survivers cannot enter, build or destroy.

Builders can enter, but cannot build or destroy.

Moderators can enter and do what they like.

I see:

Survivers work - they cannot do anything,

however - Builders cannot enter (or build or destroy)

and worst of all - Moderators cannot enter, or build, OR destroy.

Seeing as each group inherits the previous groups permissions in the group 
manager, this seems to have a bad effect on this.

What version of the EpicZones are you using?
latest - 0.20.1

What version of craftbukkit are you using?
lastest rec - 740

What version of Permissions are you using?
Essentials group manager Latest Release Build: 2.2.7

What other plugins are you running?
Essentials + ess.chat (not protect plugin)
antigrief,
big brother,
speedsign,
burning mobs,
growbie,
war,
multiinv,
natural giants,
porte coulissante,
backup,
snowballz,
heroic death,
lampstone,
worldconfig,
wormhole xtreme worlds,
stair drop,
light switch,
fence stack,
super pickaxe,
weather control

Please provide any additional information below.

The higher ranked groups seem to inherit nodes such as "build:deny", when they 
should be allowed to build.

Thanks in advance for resolving this issue. This plugin is amazing and I hope 
there is a fix

Original issue reported on code.google.com by greg...@outlook.com on 30 Apr 2011 at 5:09

Attachments:

• config.yml
• test.yml
• groups.yml
• server.log

[GoogleCodeExporter]

This should be fixed in .21 please report back.

Original comment by jbla...@gmail.com on 4 May 2011 at 5:24

• Changed state: Accepted

[GoogleCodeExporter]

Hi,

The new version is not compatible with my multi-world plugin, Wormhole Xtreme 
Worlds;

http://forums.bukkit.org/threads/admin-tp-wormhole-x-treme-worlds-v0-4-multi-wor
ld-management-protection-740.13177/

It is impossible to test anything yet. 

When I disable the multi-worlds, the plugin will load. Otherwise, the server 
log states: 

 [EpicZones] Detected Multi World Plugin > WormholeXTremeWorlds > Enabling...
2011-05-05 13:41:32 [INFO] [WormholeXTremeWorlds][v0.4]Enable Beginning.
2011-05-05 13:41:32 [INFO] [WormholeXTremeWorlds]Attached to Permissions 
version 2.5.1
2011-05-05 13:41:32 [INFO] [WormholeXTremeWorlds]Help plugin is not yet 
available; there will be no Help integration until it is loaded.
2011-05-05 13:41:32 [INFO] [EpicZones] error starting: null Disabling plugin
2011-05-05 13:41:32 [INFO] [EpicZones] version 0.21.1 is disabled.

Thanks again!

Original comment by greg...@outlook.com on 5 May 2011 at 3:44

[GoogleCodeExporter]

Just in case, v.23 has the same error after the multi worlds loads, as i quoted 
from the server log above... Something must be up with the new global zone 
implementation.

Original comment by greg...@outlook.com on 7 May 2011 at 7:23

[GoogleCodeExporter]

Thanks, I'll give it a look over.

Original comment by jbla...@gmail.com on 9 May 2011 at 9:35

• Added labels: Milestone-Release0.24, Priority-High, Type-Issue

[GoogleCodeExporter]

Original comment by jbla...@gmail.com on 9 May 2011 at 9:37

[GoogleCodeExporter]

Original comment by jbla...@gmail.com on 10 May 2011 at 2:54

• Changed state: Coded

[GoogleCodeExporter]

Brilliant :) Can't wait for the release. I'll test everything once it gets 
running again, I'm still using the old 20.1 simply because it's stable . thanks 
again!

Original comment by greg...@outlook.com on 10 May 2011 at 3:14

[GoogleCodeExporter]

Original comment by jbla...@gmail.com on 13 May 2011 at 1:56

• Changed state: Released

[GoogleCodeExporter]

Hi Jblaske,

The new version works wonderfully with the multi worlds now :), and I was given 
proper time to test the mod. However, it still seems to be the case that groups 
are "inheriting" the 'build:deny' or similar nodes from other groups... eg.

An example - I have two groups - 'builders' and 'admins'

Lets say, in my group manager configuration, that 'admins' inherit all 
permissions from 'builders'. I then set the builders to build:deny and 
destroy:deny in game, using the /zone perm (group) (node) (allow/deny) command. 

I also set admins to build:allow and destroy:allow, but because the system for 
checking permissions goes through "Is parent denied?" first, this doesn't 
change anything. If I explicitly allow a specific player name, then yes they 
can build even if their group is build:deny.

Simple way to get around this is to remove the inheritance system in my group 
manager config which instantly solves the problem.

Apart from that,it works beautifully, - it only means every time i want to add 
a permission, I have to add it to all classes, not just the lowest rank, which 
is only a minor issue.

This issue can be partly fixed by changing the permission check order for the 
parents around - instead of having it as "parent:deny" first, have the 
parent:allow. This way, for people who wish to keep inheritance, they only have 
to remember to set all the groups they want to allow to build first. 

A full fix would somehow require disallowing group manager to inherit nodes 
that are part of this plugin, something somewhat more difficult I think.

Bravo again, though, on this amazing plugin. I hope you read this!

Original comment by greg...@outlook.com on 14 May 2011 at 5:00