filter "!help" command to only show enabled commands

[gkspranger]

as a YB developer/operator, i want to only show "enabled commands" when a YB user executes the "!help" command, so that i don't have to have unpleasant conversations about "why" said YB user does not have access to "hidden" commands

i see that there is a new function called "command-enabled?" .. i see it is used to determine what commands are enabled within YB ..

can we use that function to only add to help docs IF the command is enabled ??

unfortunately, because i am such a clojure/YB noob, i am unsure where to add this conditional ..

i found the add-docs function, but i also see in hooks.clj:145 there is a reference to add-docs -- so not sure where the "filter" should occur ..

thanks for the help !!

[devth]

Makes sense!

Currently help itself could be disabled via blacklist/whitelist. Do you think it should be excluded from whitelist/blacklists?

Yes, I think using command-enabled? to conditionally add help docs would be an easy solution.

[devth]

I think it makes sense to exclude help from white/blacklists as it's more of a meta-command, and prevent disabled commands from being added to docs. Will put together a PR soon!

[gkspranger]

sorry, just seeing this now -- i thought GH auto-alerted me when issues i open are updated .. guess not ..

anyhoo -- yes, i think excluding HELP from "the lists" make total sense, since it is THE discovery mechanism users use to find out what they can do with their bot ..

thanks !!

[devth]

No problem :) working on it later today!

[devth]

I have this working locally. Do you think alias and category should be excluded from white/blacklists too?

• category is more of a meta-command.
• Aliases are more about composition or parameterization of commands. But it might get messy trying to filter aliases by whether or not they rely on enabled commands

[gkspranger]

hi there -- great question ..

quick answer is "no, do not exclude !alias OR !category" .. i think those are part of what i consider to be "foundational" commands -- along with !help AND (now that i know more about it) !channel .. those are commands that support using other commands -- like you said :: meta/composition ..

that said, after sitting and learning and pondering about aliases -- i don't we should ever exclude any "alias" that is created with the !alias command << to make things even more complicated for you :sorry:

let's think this through ::

1. i am a user
2. i become aware of commands available to me via !help -- including !alias
3. i run "normal" commands all day long, and am quite happy, because i am productive
4. BUT THEN my requirements for "custom commands" begin to grow so i can become even more productive
5. i use !help to learn more about the !alias command (and possibly !channel), and begin to use it to create "new" commands << again, these "alias" commands are only created with commands i know about via the !help command (which is already being filtered) -- so i don't need to an alias for non-command-enabled? commands ..

does that make sense ?? while we are excluding alias commands (and their internal contents) from the command-enabled? check -- i think that is a safe exclusion because users will only be creating aliases from commands they already know/discovered from !help ..

otherwise -- if it becomes too difficult OR doesn't seem like a clean solution to NOT check alias commands from the whitelist/blacklist -- then in my brain i would think we don't consider it a "foundation" command and allow it/!alias to be excluded -- since we would need to allow created aliases via the whitelist (or i guess not exclude them in the blacklist) ..

i hope this all makes sense ..

again, my thought process is that i need to slowly roll out specific commands to users to allow them to be more productive (deploy <app> to <env>), show ec2 status for <app> in <env>), while allowing them to be somewhat creative in how they use the bot ::

!category list deploy
..
!channel set app = login ;; while in the login channel
!alias dep2dev = "deploy `channel settings app` to dev
..
!dep2dev ;; while in the login channel

[devth]

This is awesome! Thanks for helping me think through it. Yes, makes sense. I think I'll build it as suggested, then we can play with it and make adjustments from there if we feel the need.

When aliases are evaluated, each command it composes will be run through the command-enabled? check, so if a user was trying to be clever and use aliases to gain access to disabled commands, it wouldn't work.

[devth]

This is done, as of [yetibot/core "20200528.202014.9d1403f"]!