See JENKINS-10827. Doesn't the proposed workaround work in your case?

Sure, this works. But not everyone is aware, that it is possible to ask for help in a query session. Also this opens up possibilities to spam for other people, which leads to the bot being kicked. We sometimes have angry players in http://stendhalgame.org that have been banned from the game and then want to annoy us. Giving them the possibility to easily spam with that bot and then letting it disappear causes unnecessary work for us.

I think it would be reasonable to reply to help in a query session, no matter from what the help request came.

By 'query session' you mean private chat?

No, I meant the fix in JENKINS-11606 to disable commands altogether for a channel.
If you're concerned about people in a channel acting 'malicious', you might want to do this anyway.

Yes, I meant in private chat.

Completely disabling commands is not a real option, as we make heavy use of this very convenient option. I think, just replying to help in private chat would be simpler than implementing a system that checks if the user is authorised to issue that specific command. This would be some kind of way in the middle between rights and total disabling that feature.

I believe this issue is multi-fold and currently:

• requesting "help" in a private chat with the jenkins IRC user works and does not spam shared room channels (so the declared goal of this issue is achievable for "good actors")
• requesting "help" in a shared room channel indeed does not cause a private-chat reply, so the "spamming" problem is still there
• very long lines posted by the jenkins IM client, e.g. a "queue" request with many agents listed as unable to pick up a job due to label constraints, to a private chat can still get it disconnected from all chats (will come back in a few seconds)