WORLDGUARD-3215 - Reported by TNTUP

The global region chest-access is set to deny, but regions owned by players should override the global flag like as BUILD DENY set in global.

global: chest-access: deny > racooncity: (no chest-access flag) > rac78: (no chest-access flag) = Player Krackedbone owns rac78, cannot open containers.

global: build: deny > racooncity: (no build flag) > rac78: (no build flag) = Player Krackedbone owns rac78, can place/break blocks.

chest-access should do the same thing as build's flag. Going to revert to WG 5.9 while waiting this fix (I did a backup before going to WG 6

Comment by PseudoKnight

This sounds like a personal preference rather than a bug. Also, the build flag isn't a place/break blocks flag. It should only be rarely used, and it's not a good model for other flags.

Did you try "-g nonowners chest-access deny" in global?

Comment by TNTUP

I need to use the BUILD because I always used it in WG 5.9...

Tried your command, doesn't work, it says Region flag chest-access set on global to deny and Region group flag for chest-access set.

Still can't open chests in own region/subregion (Used AySakie my other alt for test)

Comment by PseudoKnight

More often than not you don't need to use the build flag, and given your post above it sounds like you don't understand what it's doing. That's fair enough, as it is not a simple flag, but it does warn you not to use it in the documentation.

I'll test some solutions for the chest-access thing. I don't use the beta, but I have a test server for these kind of problems.

Comment by PseudoKnight

Currently it appears the tried and true method of setting a player/group as a member or owner of global works best for this. It denies building/chest/etc in non-regioned areas, which appears to be what you want.

I wasn't able to get chest-access method to work, because it doesn't seem designed for this.

This is one thing I look at when looking at the flags for the beta:
https://github.com/sk89q/WorldGuard/blob/master/src/main/java/com/sk89q/worldguard/protection/flags/DefaultFlag.java

Comment by TNTUP

I would need this ASAP because I wont update to 1.8 (spigot) with WG 6 because of this critical issue.

Comment by PseudoKnight

Did you read my response? Do you have a reason to not use the provided method? Because you haven't mentioned one yet.

Comment by SilberRegen

Okay, I did another testing series.
The problem is neither the priority nor the parents. These still have the same functionality and work perfectly fine with our settings.

If no flags are set in any region and parents are set like I showed in the previous post, chests access works perfectly fine.
The problem is the new functionality of the use flag, as it seems there is no way to separate inventory and button/levers/etc. access. I tried every combination and the chest-access would also work with your shown setting. The use flag does not.

We want everybody to be able to use buttons/etc. everywhere regardless of their regions member status, if not specified otherwise. This doesn't work anymore without affecting chest-access.
Maybe you know another way?

I am really thankful for your quick responses and your invested time in this issue.

EDIT: Just noticed, that normal doors are affected by this, too. Didn't think of that before...
This is a no-go on our server as it blocks people from exploring. I am really unhappy with this. :(

Comment by PseudoKnight

Not happy myself. --What you're asking is possible by setting the use flag on the regions in question--, just not through global. You can't change it back to the way it was. But you SHOULD fix your regions to priorities are correct.

Comment by PseudoKnight

Well, technically it's also possible with a fork, since it's open source. So if sk89q decides to keep it this way after beta, then there are solutions.

Comment by SilberRegen

Thank you so much.
It will require some reflagging, but it's manageble.

I found it worked with this settings:
global (chest-access: deny (nonmembers), use: allow)(owners/members: none) priority: 0
|->spawn (no flags) (owners: none, members: some trusted players) priority: 0
|->spawn_houseofplayer (chest-access: allow (members)) (owners: none, members: player) priority: 1

The parent stuff is not needed for this flag configuration, but there are some other regions where it is required so I left it as it is.

EDIT: Setting global to priority -1 seems to work to and it less work.
EDIT2:
This is what we are sticking with now, works and requires the least amount of work.
global (chest-access: deny (nonmembers), use: allow)(owners/members: none) priority: -1
|->spawn (chest-access: allow (members)) (owners: none, members: some trusted players) priority: 0
|->spawn_houseofplayer (no flags) (owners: none, members: player) priority: 0

Comment by seema

i can confirm this

Comment by TNTUP

I tried it yes, no luck... Usually BUILD should deny chest interaction or its because I've set USE ALLOW (To let players to dis/mount horses from a plugin HorsesStables, that I couldn't find a way to allow this :/

Comment by PseudoKnight

Don't use build deny unless there are no other solutions.

Comment by TNTUP

Can't. Players would be able to build outside of town regions..

Comment by PseudoKnight

Except they can't when you add a player/group as a member or owner of global, as I said above.

Comment by SilberRegen

I do have a similar issue with the new world-guard version.
Our players own regions within a spawn-region (parent), which itself has global as parent.
In the old version I never had to touch the chest-access or use flag, people could use buttons everywhere, if not denied in a specified region and access chests where they have permissions. This is how it worked for years.
Now either everybody can open chests (allow on global) or nobody (deny on nonmembers), allow just for members doesn't work. I also had to allow the use-flag in the new version, which was unnessecary before. I tried many possible combinations of flags, but eventually had to downgrade, losing all the region-member-datas in that process.
Setting flags for every single region is not what I want to do.

Comment by PseudoKnight

WG6 beta changes many things. Most of these changes are listed in the changelog. Please read it as there may be other changes that you may not be aware of. One of those changes was a "Deny by default" approach in protected regions, which mostly affected use interactions. While I don't necessarily agree with that approach, I understand it. There are some interactions I'd love to be denied by default, like repeaters and note blocks.

Now either everybody can open chests (allow on global) or nobody (deny on nonmembers), allow just for members doesn't work.

Allow just for members is default behavior. It's only different if you changed something.

Setting flags for every single region is not what I want to do.

Certain special server setups will require setting flags for most regions. It would be nice if there were a default flags option in the config. However, there's nothing about your server that suggests you need to set all those flags.

Comment by SilberRegen

Thank you for your fast answer.
I did read the changelog and according to the log, setting the flags use - allow and chest-acces deny for nonmembers should do what I want (allow everybody to access buttons etc. but only members of a region to chests).
But in the child regions it does not. In this setting the members of the child regions can't access their chests. Removing the chest-access flag results in them also accessing every chest in the parent (because of use allow).

Maybe chest-access doesn't override the use flag setting properly/the way I think it should?

Comment by PseudoKnight

I think what's happening is that you're not using priorities? You at least never mentioned them, and the symptoms suggest as much. Hard to tell what you're doing and what you're not doing based on the explanations.

'Chest-access' doesn't override 'use'. For a simpler explanation, both 'use' and 'chestaccess' permissions are checked when players right click a chest. --If one of them is denied for that player, then the action is cancelled.-- Actually, this was changed. If build is allowed, then it doesn't check these. If build is denied, then it does check these, and if one is allowed, then it is allowed. It's kind of odd.

Comment by SilberRegen

Again, thank you very much for your quick response.

No, the priority of all regions is 0.
The structure is:
global (chest-access: deny (nonmembers), use: allow)(owners/members: none)
|->spawn (no flags) (owners: none, members: some trusted players)
|->spawn_houseofplayer (no flags) (owners: none, members: player)

I understand: use allows access for every player to access inventories, buttons, levers, repeaters etc.
chest-access on deny for nonmembers should cancel inventory-access for everybody who is not member/owner of a region. Chest-access allow for members in this combination would also allow nonmembers to access, since use is allowed, so this is not an option.

But with the used structure, the player of the spawn_housofplayer region can't access his chests.
Would changing the priority of global fix this problem? (Does the default setting of the child on the same priority interfere with the parents settings?)

Comment by PseudoKnight

Deny takes priority in overlapping regions of the same priority. If a player is only a member of one of two regions for that location, then they'll be denied permission. However, if one of the regions has a higher priority, then the player must only be a member of that region to have permission. Both 'use' and 'chestaccess' are influenced by this. In many cities, for example, you'll find the outer region will have the lower priority. This covers the streets and common areas. The inner regions are plots/houses given to various players. They have the highest priority.

global: pri 0
city: pri 0, members: trusted players
plot: pri 1, members: home owner

In this situation, parent settings are unnecessary. You usually only use that when there's a set of flags and/or members you want the child region to inherit. In your case, setting spawn_house's parent as spawn means trusted players also have permission in spawn_houses, even if they're higher priority. In practice, I find I rarely use parents.