define channel defaults via a command and/or make configurable

[gkspranger]

as a YB dev/ops person,
i would like my channel defaults to be defined via an enabled command and/or configureable,
so that my channel settings are representative of my initial desired state

https://github.com/yetibot/yetibot.core/blob/master/src/yetibot/core/models/channel.clj#L19-L32

so let's talk about "defined via a command" .. i was looking at how you define a commands "category" via simple metadata ::

https://github.com/yetibot/yetibot.core/blob/master/src/yetibot/core/commands/echo.clj#L8

it would be neat if i had the option to create channel defaults in the same manner ::

{:yb/ch {:name "Greg"}}

and so if a command is enabled, when YB enters a channel -- it will have the aforementioned defaults ..

so let's talk about "configureable" .. i was looking at the config.edn example -- and i do see a reference to "jenkins" and "default" -- and as you are aware -- "jenkins-default" is a default channel setting ..

https://github.com/yetibot/yetibot.core/blob/master/config/config.sample.edn

but when i try and set this in my config.edn and restart YB -- when i check channel settings (<< even on new channel joins) -- i see that the channel setting is what is in the previously linked code ..

;; my simple test
:jenkins {:default {:job "hello world"}}

that makes sense, simply because the config is NOT a channel default, but a jenkins default -- and when checking YB code (<< note, not core) -- i think i see references to it ::

https://github.com/yetibot/yetibot/blob/master/src/yetibot/models/jenkins.clj#L29-L30

one thing i want to call out is that this default is getting set even tho i do not have any jenkins command enabled .. so it's possible a inexperienced YB user will look at their channel settings, see references to "jenkins" and "jira" and the like -- and wonder why there is a channel setting for it when said commands do not even exist to them ..

it would be great if there is a way to NOT show these defaults if the command doesn't exist AND/OR i simply don't want it there ..

finally -- if i had to choose between one or the other -- i think i would want to be able to define via a command's "metadata" >> sorry, i don't know want to call this line ::

https://github.com/yetibot/yetibot.core/blob/master/src/yetibot/core/commands/echo.clj#L8

i hope this all makes sense ..

thanks !!

[Trevor Hartman]

Great stuff. This brings up a bunch of thoughts/questions.

1. Just realized the command loader should check white/blacklist config and avoid loading disabled commands therefore reducing the memory footprint of a yb. Opened #142

2. I'm thinking the channel config defaults defined at https://github.com/yetibot/yetibot.core/blob/68f7811b9e2e421ac92b52bd3bf0cffc6c39abd7/src/yetibot/core/models/channel.clj#L19-L32 are kind of gross as they leaks details from commands into this single place, a side effect of which is potentially showing channel config for disabled commands. Commands should indicate that they can consume channel-specific config in their own help docs, or more generally if we tackle #130 The great configuration overhaul of 2020 then potentially any command params can have channel-specific defaults, and maybe even user-specific defaults as well. Which would be quite powerful.

3. and i do see a reference to "jenkins" and "default"

   right, this is a different mechanism from channel defaults. It's more like a global default. I think if we do end up tackling #130 we could tie these all together with a very clear priority override order: user specific, channel specific, global default, and abandon these kind of one-offs in config.

4. i think i would want to be able to define via a command's "metadata"

   yes this is the correct term. You are saying you'd want the fact that the command can consume channel-specific settings to be baked into the metadata, right? This makes sense for how things work now, but again if we impl #130 then this becomes even more general and doesn't need to even happen at the command level.

[gkspranger]

thanks for the clarification concerning underlying YB components -- it creates a more clear picture about what is happening, and what is available to me as a YB dev/ops person ..

i have seen references to #130 and wondered how it would affect my current ask .. if it makes sense to drop this issue and instead focus on #130, then by all means -- please do so and i can adjust to the new norm when it the time comes ..

i REALLY like the idea of a priority override order -- that would greatly expand the abilities of the !alias command (<< others too i'm sure), providing a tremendous level of personalization per command .. i can just see it now

#global
deploy to dev ->> "please set a channel or personal setting"

# channel setting "app=login"
deploy to dev ->> YB triggers deploy of "login" app to dev

#personal setting - "app=yb" (i am part of the "login" app team)
deploy to dev ->> YB triggers deploy of YB app to dev

anyhoo -- all good stuff