OpenInv

4M Downloads

Lands plugin region prevents using /oi commands

homerek111 opened this issue · 17 comments

commented

as title says - Lands plugin's region prevents using /oi commands if executor does not have access to open containers on the region that player is standing on.

Would be nice if openinv plugin override that Land's protection

lands plugin: https://www.spigotmc.org/resources/lands-%E2%AD%95-land-claim-plugin-%E2%9C%85-grief-prevention-protection-gui-management-nations-wars-1-21-support.53313/

commented

Oh, that sounds like they're blindly blocking the InventoryOpenEvent. You'd need to ask them to not block it for player/ender chest inventories. Ender chest access control can be done using the PlayerInteractEvent instead by checking the interacted block.

Is this opening an inventory of the type InventoryType.PLAYER? Lands does not cancel the event if the inventory type is for example PLAYER.

commented

Yes, and additionally it is an instance of PlayerInventory. Bear with me, this is a little messy because it matches the way CB inserts itself into internals:

OpenPlayerInventory (the internal corollary to CraftPlayerInventory) always returns InventoryType.PLAYER:

@Override
public @NotNull InventoryType getType() {
return InventoryType.PLAYER;
}

The internal Bukkit implementation used depends on the target and permissions, but is always an OpenPlayerInventory or its only subclass, which does not override type:

@Override
protected @NotNull CraftInventoryView<OpenChestMenu<OpenInventory>, Inventory> createBukkitEntity() {
org.bukkit.inventory.Inventory bukkitInventory;
if (viewOnly) {
bukkitInventory = new OpenDummyInventory(container);
} else if (ownContainer) {
bukkitInventory = new OpenPlayerInventorySelf(container, offset);
} else {
bukkitInventory = container.getBukkitInventory();
}

This includes the default inventory if called from other areas:
@Override
public @NotNull org.bukkit.inventory.Inventory getBukkitInventory() {
if (bukkitEntity == null) {
bukkitEntity = new OpenPlayerInventory(this);
}
return bukkitEntity;
}

/e: And just in case it helps, here is where OI calls the InventoryOpenEvent when executing /oi and /oe:

menu = CraftEventFactory.callInventoryOpenEvent(player, menu, false);

commented

Actually, now that I'm looking at it

is always an OpenPlayerInventory or its only subclass, which does not override type

is not true, the view-only dummy copy does not report type. That's a bit of a mess, eesh.

@homerek111 Is the executor of the command opening view-only copies? /e: I have opened #273 - please let me know if the build from https://github.com/Jikoo/OpenInv/actions/runs/12694421974 resolves this for you.

Executor should be able to open both types of /oi inventories on Lands regions (view only and editable modes)

I will test that build in a moment - my server is running on 1.21.1 - would that work for it…?

commented

Actually, now that I'm looking at it

is always an OpenPlayerInventory or its only subclass, which does not override type

is not true, the view-only dummy copy does not report type. That's a bit of a mess, eesh.

@homerek111 Is the executor of the command opening view-only copies?
/e: I have opened #273 - please let me know if the build from https://github.com/Jikoo/OpenInv/actions/runs/12694421974 resolves this for you.

commented

Executor should be able to open both types of /oi inventories on Lands regions (view only and editable modes)

I was asking if the problem was specifically with view-only UIs.

I will test that build in a moment - my server is running on 1.21.1 - would that work for it…?

At this time I only support 1.21.3 and 1.21.4, sorry. My policy to avoid bloating the file is to support the last two NMS packages on a major version (and normally the last release of the previous major version, but the new UI rewrite prompted me to drop that earlier).

commented

in that case i can't use that on my server atm so can't tell you if it fixes the issue :/

That's unfortunate, but it is what it is. Please answer the question though - is the problem exclusively with view-only UIs on your server? That is the only problem I can find with what OI is doing.

commented

Executor should be able to open both types of /oi inventories on Lands regions (view only and editable modes)

I was asking if the problem was specifically with view-only UIs.

I will test that build in a moment - my server is running on 1.21.1 - would that work for it…?

At this time I only support 1.21.3 and 1.21.4, sorry. My policy to avoid bloating the file is to support the last two NMS packages on a major version (and normally the last release of the previous major version, but the new UI rewrite prompted me to drop that earlier).

in that case i can't use that on my server atm so can't tell you if it fixes the issue :/

commented

Perfect, thank you. In that case the linked PR should resolve it for future versions.

thanks... sadly i cant use that on my server :P at least it is fixed for others xd

commented

in that case i can't use that on my server atm so can't tell you if it fixes the issue :/

That's unfortunate, but it is what it is. Please answer the question though - is the problem exclusively with view-only UIs on your server? That is the only problem I can find with what OI is doing.

i dont really understand the question - what is view-only UIs

  • the issue happens when you execute command /oi <nick> for the player that is standing on his land where you dont have access to open containers
commented

i dont really understand the question - what is view-only UIs

  • the issue happens when you execute command /oi <nick> for the player that is standing on his land where you dont have access to open containers

Ah, sorry. A view-only UI is the version of the inventory that can be viewed but not edited, i.e. from not having the permission openinv.inventory.edit.other.
Internally this is a separate inventory because it is designed to block certain bad behavior from plugins (there's a sorting plugin that will sort any top inventory, for instance). Looks the same, functions differently, including the type reporting, which is probably the issue you're encountering.

I'm asking you whether the user who is being denied access in a land would ordinarily not be able to move items in the specific inventory they are being denied access to, i.e. if you are denied and then attempt to open the same person's inventory, can you move items in it when it opens?

commented

i dont really understand the question - what is view-only UIs

  • the issue happens when you execute command /oi <nick> for the player that is standing on his land where you dont have access to open containers

Ah, sorry. A view-only UI is the version of the inventory that can be viewed but not edited, i.e. from not having the permission openinv.inventory.edit.other. Internally this is a separate inventory because it is designed to block certain bad behavior from plugins (there's a sorting plugin that will sort any top inventory, for instance). Looks the same, functions differently, including the type reporting, which is probably the issue you're encountering.

I'm asking you whether the user who is being denied access in a land would ordinarily not be able to move items in the specific inventory they are being denied access to, i.e. if you are denied and then attempt to open the same person's inventory, can you move items in it when it opens?

as i tested it right now:

when player has permission to edit openinv.inventory.edit.other he can open player's inventories correctly
when he does not have that permission (so he can only view) - it blocks him

so the issue happens only for view-only

commented

Perfect, thank you. In that case the linked PR should resolve it for future versions.

commented

OI intentionally does not bypass protection plugins. This allows for more complex setups where mods can have access to some but not all areas, for instance. The plugin presumably has its own permissions and system for bypasses that you should use in conjunction with OI.

If you really need the bypasses on all the time whenever OI's administrative modes are on, you can set up your own custom command via commands.yml that runs all the necessary commands, i.e.

aliases:
  inspection:
    - silentchest $1
    - anychest $1
    - example:bypass $1

You would then run /inspection true in game to execute /silentchest true, /anychest true, and /example:bypass true.

commented

OI intentionally does not bypass protection plugins. This allows for more complex setups where mods can have access to some but not all areas, for instance. The plugin presumably has its own permissions and system for bypasses that you should use in conjunction with OI.

If you really need the bypasses on all the time whenever OI's administrative modes are on, you can set up your own custom command via commands.yml that runs all the necessary commands, i.e.

aliases:
  inspection:
    - silentchest $1
    - anychest $1
    - example:bypass $1

You would then run /inspection true in game to execute /silentchest true, /anychest true, and /example:bypass true.

@Jikoo But Lands plugin is protecting physical containers that are placed on the region (like chests/barrels)

  • why would it block /OI command that shows player’s inventory (not chest/barrel)
commented

Oh, that sounds like they're blindly blocking the InventoryOpenEvent. You'd need to ask them to not block it for player/ender chest inventories. Ender chest access control can be done using the PlayerInteractEvent instead by checking the interacted block.

commented

Hey @homerek111, just wanted to let you know that as of e4fdd61 Paper 1.21.1 will be supported again until whenever 1.22 drops. Presumably I'll be cutting a release for 5.1.8 in the next coming days.

commented

Hey @homerek111, just wanted to let you know that as of e4fdd61 Paper 1.21.1 will be supported again until whenever 1.22 drops. Presumably I'll be cutting a release for 5.1.8 in the next coming days.

Sooo I will be able to update the plugin on 1.21.1 server? Nice! Thanks :)