Log item manipulation

[Bloodlex]

Hello,

I think it would be nice to have a feature, to log everything that happened in someone else's inventory. It would allow me to perform better supervision over my server stuff.

For instance, it could be a simple .log file with information which item has been transferred to/from another player's inventory. It could log it after every drag&drop or provide a summary after the inventory editing is done. I think I like the idea with summary better, but I don't know exactly how hard it would be to implement that.

Maybe this log could be also accessible via some command that would for instance open a transfer history for a specific user that performs an action (a moderator or admin in that case) or for a player that is a subject to inventory manipulation (what has been taken from or given to).

Sometimes there are discussions on my server, that stuff is accused of taking something from player inventory, I would like to have some proof that it happened or not.

I hope you like my idea, please let me know how doable is that. Thanks a lot!

Best regards,
Bloodlex

[darksaid98]

I see this recently got moved into the GitHub project. Recently had some staff members request this as it would be very convenient. ❤️

[Jikoo]

This is one of the longer stretch goals - features like this will be addon plugins. Presumably this will hook Prism, possibly CoreProtect or LogBlock or whatever if their APIs are usable. Don't really want to write a logging and lookup system myself, and encouraging people to use proper tools sounds nice.

Addons won't happen until at least after I cut 5.0.0, which is a pretty large overhaul.

[darksaid98]

That sounds awesome.

In terms of logging, I was thinking more of something simple like darksaid98 Removed x1 "Renamed Diamond Pickaxe" from Someusers inventory or darksaid98 Added x1 "Renamed Diamond Pickaxe" to Someusers inventory being sent to the console.

Although quite verbose it could be exposed as a boolean in config, and would still expose edits in the server log for administrators to access.

[Jikoo]

The problem is that, as you pointed out, that's pretty verbose. Building a system with rolling logs isn't hard (the logging APIs included in Spigot make that a snap), but retrieving that information in game would be a massive PITA from raw logs. You'd have to load, parse, and filter all of the information. That consumes a lot of memory and I/O time, which means threading and resource consumption limiting. Mandating logging plugins for logging features will keep me sane and make the feature much more achievable. Being able to piggyback Prism, for example, means that lookups are as simple as using Prism normally, so all I'm on the hook for is presenting the information to Prism. Have I mentioned Prism? Prism is great. I WILL write an essay on how good it is, do not test me.

I also don't think a system where admins are expected to manually search logs is a good idea, that sounds like an awful user experience. Even with the power of grep on my side I didn't love it when I had to search logs, and I'll be honest, most of the people I administrated with would manually search files if they had to locate something. I really don't want to enable that, because I value their time even if they don't. I know it sounds harsh, but the vast majority of administrators are people who have little to no experience with server management. Most servers are run by people who know just enough to start a server and install plugins.

One of my secondary goals is to encourage people to move away from /searchcontainer - not only is it easier to locate things pretty much anywhere with a logging plugin, it's also safer and gives actual information about how an item got to its current location. More exposure to real logging plugins means more people hopefully realizing /searchcontainer is awful and not using it.

[Moosfet]

Don't let the perfect be the enemy of the good. Just dumping some text to a log file requires little development time and provides something, which is better than nothing, until the time comes that you can implement an ideal solution.

At the moment I have server staff who, perhaps I can trust them, but I don't want to have to trust them. So when they find stolen items in someone's inventory, they have to ask me to retrieve them, because if I give them full access to /oi and /oe then they can steal from old players who haven't been on the server in a few years and these thefts might go undetected for years, after which a lot of damage has been done, and even then it might prove impossible to figure out who has been committing the thefts. Maybe I can trust my staff, but also I have a responsibility to the rest of the player base to not take unnecessary risks, and so it's better if I don't have to trust the staff.

What would resolve this conflict is some accountability provided by logging. If, every time a staff removes something from someone's inventory, this were logged somewhere, then I can catch rogue staff immediately.

I already have a Discord bot that ChatGPT helped me write that can post text in Discord. I could easily script it to post lines from a log file to our #staff-chat to report when staff give or take items from inventories. Then, if such lines don't come along with an explanation from staff about what issue they were resolving, I'd know that someone is just stealing things. It would allow me to both not waste my staff's time by making them come to me, and allow me to keep my obligation to the player base as a whole to not put their work at unnecessary risk.

As for making this accessible to those who can't script, I suggest an option to log to Minecraft chat. Legitimate uses of /oi and /oe are once-a-day events, so it wouldn't produce a lot of spam, and it's easy to install a plugin that bridges Minecraft chat to Discord, providing a place where such messages might be seen even if items are stolen when no one else is on the server. I think players might even prefer seeing these messages in chat to playing on a server where staff might be stealing things with no accountability because the thefts are untraceable.

Again, this might not be the ideal solution, but it's quick and easy and you can do ideal at a later time.