/report <player> <reason>
confuser opened this issue · 48 comments
Log both actor and player locations including world
Look into attaching the last few minutes of chat history to the report, as well as an API for other plugins to add their own meta data to the report, such as NoCheatPlus violations.
This gives a start to an appeal/report system.
GUIs always contain dupe glitches, so I don't particularly want to implement one. That being said, it could quite easily be added via a separate plugin. As for your other questions, yes, they'll be able to see the /reports if they're on other servers, however that is not yet implemented.
@confuser GUI's are not pretty to work with as a dev, but generally, if implemented properly, they do not contain glitches. I use the plugin ChestCommands from filoghost for quite a while now, and there hasn't been a glitch regarding it for forever.
MyCommand also offering kind a chest command and works well too. Using this for quite a while now and did not have any reports about glitches (yet).
Would players with the /report be able to receive the report server wide? Such as if they're not in that specific server, they would still be able to receive the notification of a report given? Would there also be a possible way to imminent a configurable GUI based reporting system?
I used this for the first time the other night, I accidently submitted the same report a second time and it threw an error in the console, not using Unique ID's in the database? We couldn't open this up to players as it could just be spammed to high hell without a cooldown, or limit for players.
to re-illiterate over the web-ui standpoint, Most reports would be made when there are no staff online, so they would need a clear way to monitor and read over reports in a list format with as much detail as possible. The exact position the report has been made (/getpos) Maybe take a snapshot of the last 100 lines of the console log per report so we can gather whats been happening, what commands have been used by who and whats been said in chat/privatecaht/groupchat etc. If reports are limited to amount or with a cooldown then collecting that much data wouldn't be any issue.
The $player thats been reported could do an auto lookup to calculate any previous punishments and put that as part of the report on the webUI. It would be helpful to collect the position of the offending $player aswell at the time of the report.
@FrozenBeard please read this issue in it's entirety. The command is not yet finished and most of what you have suggested has already been discussed, ergo why this issue is still open.
As of latest dev build:
- Cooldown added, configurable in config
- Added location storage alongside reports
- New separate plugin demonstrates how other plugins can assign data with these reports
- Logs previous console output, with a configurable line limit, as well as ways to ignore certain lines either from a basic contains check, or regular expression
- https://github.com/BanManagement/ReportsLogger
- Not yet available for download, expect it on the CI server soon. In the mean time feel free to compile yourself
Available for download https://ci.frostcast.net/job/ReportsLogger/
Forgot to mention, but ensure you delete the existing reports table and allow the plugin to recreate it to solve the unique issue @FrozenBeard mentioned
Is this going to be a separate plugin @confuser or just for dev testing?
@FrozenBeard It'll remain separate, it's using newer features from Google Guava which aren't bundled with 1.7 versions of craftbukkit/spigot which BM itself still aims to support.
I believe now all that needs to be done to close this issue and be feature complete is a way for reports to be viewed in game
Yes, however they can simply remove the unique index from the player_id column alternatively.
Forgot to mention, but ensure you delete the existing reports table and allow the plugin to recreate it to solve the unique issue @FrozenBeard mentioned.
@confuser Will this affect all users that are upgrading from 5.7 to 5.8 that they have to manually delete this table?
There could be a few buttons for reasons to report, but how would you manage to add a particular username within a GUI?
My two options to solve this would either be dynamically add "buttons" to the GUI from all players withing a specific radius. Bad idea though.
Or open the gui when using /report <playername> if the playername is a valid name which is currently online.
However there might be reasons to report a player offline too. Could be made toggleable.
@EvilOlaf I was under the assumption this was for reading reports only and not submitting them, as the in-game records a lot more data such as positions and recent console actions.
For the reading GUI, we need to make sure there is a way multiple server admins can log into the web-ui for a start.
Leaving notes on players only admins can see is a second, we need to talk over things, collect more data and information, An option could be to sync that data with something like mantisbug tracker https://www.mantisbt.org/ thats how we manage our servers bugs and players to be tracked.
There needs to be an an option to set if something has been dealt with, who to assign the issue to.
Please take inspiration from existing systems such as bug trackers, that's all this will be, a bug tracker but for players, it may be better to develop a solution that plugs into an existing bug tracker like open source api rich mantis.
My thinking is that the staff should be able to deside themselves if they assign a report to themselves or (with a particular permission node) to assign a report to someone else.
Auto assign to predefined team mates or even random assigns I think is a bad idea, well, in my eyes at least.
I agree in the simplicity for commands, especially for players. Not sure if it is worth the effort to provide a GUI for the report command in the second way I wrote above. /report <playername> without argument and the GUI with predefined reasons pop up.
My suggestion is to not implement a GUI for anything until the report system with all things needed like commands, storage, evaluation and whatever. When all this is done a GUI could be used to trigger those already existing commands which should be easy to do.
On the downside though, why should BM reinvent the wheel when there are already plugins that are providing these features? However, these reports are not linked into BM then ;).
Btw. maybe it is useful to create a wiki page for all the input and idea collection for the reports system. Reading all the posts here might become unhandy.
On the downside though, why should BM reinvent the wheel when there are already plugins that are providing these features? However, these reports are not linked into BM then ;).
Agreed, however, with that then comes problems with maintenance, such as features, bug fixes etc, as well as access, as many plugins seem to be going paid, regardless of quality.
The feature of associating things like console logs etc with reports is from what I've seen a unique feature to BM too. Quite a lot of plugins in the ecosystem I've come across are either buggy or not developed with actual players/owners in mind.
Btw. maybe it is useful to create a wiki page for all the input and idea collection for the reports system. Reading all the posts here might become unhandy.
Good idea, I had to originally disable it as other people were making random wikis on the project, so I'll re-enable 👍
Whilst I see the advantages of linking the web ui to the minecraft side, it should be worth noting that the Web UI is an enhancement, not a requirement to use BM, and therefore in game commands etc still must be offered to handle as much as possible.
Assigning a report to a specific player is a good idea, however, we then enter dangerous territory. Do reports get automatically assigned? If so, to whom? Which ones get assigned to which player? How do we determine this? If we go down the category route, e.g. Player X will handle hacking reports, this then adds an extra step and complexity to the user making the report. Do we then allow staff to assign a category instead, and so on.
There will be a gigantic list of requirements from multiple networks for this feature. We still need to cater for very young players, and keep it simple. I.e. /report <player> <reason> simple, nothing too complex. Obviously staff commands/GUIs etc can be a little more complex.
Heres an idea, The reporter, a player in game wanting to report a player does /report <username>, this then creates the database row and sends them a URL on screen, in game, they can click that takes them to the detailed web UI report screen. From here they can fill out more detailed information, this way the details are linked to the players positions and commands/chat.
Since most small/average servers already have a ticket system, there is no point creating a ticket system if they already exist, as I said above most have API's, so once they have submitted this information into the webui/banmanager system this could easily be linked to a proper bug tracker to keep track of issues
I forked BM with the wiki page, because I don't want to accidently edit or remove something false on your wiki page. I'll frequently add my thoughts and ideas to https://github.com/EvilOlaf/BanManager/wiki/BM-Reports
Please feel free to copy parts you like.
What about "jsoning" the stuff in chat? So clickable messages in chat to enhance the comfort. Please ignore the git links behind the # stuff if any, it is just for better visualization.
For example if a user generates a new report:
aReportingPlayer has opened report #421. Click for details.
A click on the #421 or maybe on the entire message will open the report details, either within a GUI or simply in the chat. So no more /report info 421 for example.
Just wanted to know if you like the idea before I gonna think about it even further.
Loving the ideas @EvilOlaf. I'd be interested in hearing your ideas for JSON chat messages, however, I think those should come at a later date, once the commands have been fleshed out and implemented.
The only things I'm not overly sure of is:
/report deny: Preventing just reports seems a little too small of scope. Perhaps this is out of scope for this plugin, but on the other hand, it is a ban plugin, and adding a feature that allows you to ban players from using any particular command may perhaps be more useful? e.g. /tempbancmd confuser 2h /tpa. Adding a reason would be a little difficult if sub command arguments are supported. However, I don't want to open the flood gates to other feature requests that are better off in other plugins, such as banning players from using particular items etc (i.e. WorldGuard).
/report teleport: The issue of teleporting to ones death, this could be achieved by forcing the player into spectator mode, but then some kind of exit command would be needed; there's also the possibility of this being abused. It's also 1.8 only, and I'd still very much like to support 1.7 still as there's still a high % of users running BM with it.
/report note: Seems like it would duplicate the note functionality. Perhaps this should integrated into notes instead, and a note can then be assigned with a report? I can then add a check within queries that are used for commands such as /notes to exclude anything that is assigned with a report by default. The command /report note can then just be an alias for /addnote with a particular flag variable, but with it's own permission to still be flexible by allowing certain players to create report notes, but not player notes, and vice versa.
Allowing staff to comment on reports is obviously a must have, especially for hacking reports, as they vary wildly in terms of trying to work out if the player was actually hacking or not. This would then also be possible to integrate with the web interface as hinted by @FrozenBeard
Hey @confuser,
/report deny was really meant for blocking a user creating reports only. As you mentioned there can be or probably there are already other plugins that can be used to prevent a user from using a particular command....the idea to make this timed is interesting though.
So no clue here.
The idea with using gamemode three for teleports is interesting, but has too many disadvantages. The ultimate solution might be add it and also add a compat mode for 1.7 which offers other ways for teleport.
I would still prefer a safe location check like Essentials does it for tpa request for example.
What about temporarily add god mode to the teleporting staff mate?
I already had concerns that the duplicate use of note could cause confusion. So calling it comment instead and using another shortcut for close or comment is the better solution.
Linking report comments and player notes might be useful for some, in my case I would prefer having comments and notes separated. I don't wanna have particular linked comments been wiped if the report database gets purged.
I've edited my wiki page according the notes comments stuff and added a first example for JSONing.
Another issue with chat-based stuff is when your ingame chat is heavily frequented.
For example many users chatting, then there may some notices from NCP pop up and poof 50 lines are gone. This can be really annoying.
As a solution I attach a screenshot of my ingame help library. Yes, it is german, doesn't matter, deal with it :P When you move your mouse pointer over an item the hover text will show up.
Anyway this way nothing will get lost in the chat but this is probably quite a challenge to code this. You have to worry about things like the line length. If you exceed the width and height (I use the default dimensions of the minecraft windowed mode as lead) it will not fit into the window anymore and you might beunable to read some stuff.
Web-UI? @frdmn
Would like to implement such a feature... Shouldnt really be a problem to add a reports column to the current webUI.
+1 from my side! :)
With the implementation of NoCheatPlus violations and chat/command history this would be superb, plus with the web UI it could be built on for in-depth violation reports.
Did you figure out a concept for this yet? Would love to see this feature.
No need for an extra plugin...or maybe as addon for BM?
The base of the functionality will be added into BM directly. Support for external plugins such as NoCheatPlus will be as addons and not part of BM itself.
If you mean from a technical standpoint, then yes, I've already thought of an implementation.
Reports will be stored in the following format:
id, reported (uuid), actor, reason, created, updated
Emit events when a player creates a report, addons/other plugins then listen to this and can create their own data in their own tables; e.g. BM itself will directly support locations in a new table
report_id, reported_x, reported_y... etc
Passing the table creation/structure over to addons allows much greater flexibility in terms of searching/data normalisation but it creates a somewhat problem on the web frontend as it'd need to be directly supported within their, as Java plugins won't be able to affect it.
Sounds nice so far. 👍
What I think is missing in the list of report details besides reporter, actor and so on is the world name as well as the coordinates and maybe yaw/pitch. Could be useful to teleport to a report and have the direct look at it. No need to turn around ;)
That's not missing ;)
BM itself will directly support locations in a new table
report_id, reported_x, reported_y... etc
Ah yes, my bad...lost my glasses somwhere...
Sometimes it is useful to know where a certain team member issued a BM command. For example a player has received a warning for building crap somewhere in the middle of nowhere and asks where he has had build crap. For now I have to search the logs with LB/Prism/HE and such plugins that store the location where commands have been executed.
Just as sidenote for further use of location data ;)
Is it possible to report an offline player?
Players have informed me that they wanted to report someone that's been logging in and just spamming their server IP, then left. They couldn't do it though, because the user was already offline.
Reporting offline players will be supported I guess, but you should not use the report command yet as this has not been completely integrated yet. Most stuff is work in progress and can be followed here: #557
I wouldn't say you shouldn't use the reportcommand yet.
It works fine and has helped us keep track of the bad guys so far!
(using the Web UI to see the reports)
Hm okey, did not know that this has been introduced in the WebUI already. Kind a lost track :P
@xILukasIx can you please point me in the right direction of the web UI? I would really like this all shown in the web UI.
Should the command closing the report also take care of the ban/mute options as well? That way it can be explicitly associated with the report easily.
Idea. Perhaps a command flag, such as -r <reportId> for each command (ban, mute, warn etc), which will set a report into a resolved state, and associate that as the outcome with the report?
That would work for when BM commands are the outcome. But what about edge cases where external commands are the solution instead? Are there any? What about a wrapper for this case, e.g. something like /report close <id> [command/comment]?
If it begins with /, it's a command to execute as the actor (not console), if not, a comment/note.
Hm, not sure if this will be used frequently in practice. Imaginary players will do ban XxstupidGuyxX being stupid and report close 123.
As for me I would probably not use kind a wrapper if there is any. Also what about if you need a / within your comment?
The more I think about the more this could be come quite handy. Kind a "complex" commands but also can save time if properly used.
Also what about if you need a / within your comment?
Well if it starts with a / then it's a command, so comments could quite easily contain slashes, just not at the very start. Are you thinking of cases where both a command and a comment would be required?
This is stagnating more than I'd like, so I'll be pushing out new features for this over time rather than trying to do it all in one release.
Next release will contain:
- Listing reports
- Assigning/unassigning reports to players
- Teleporting to the reported location
- Viewing a report
- Closing a report, with optionally either a command or a comment