cog

cog copied to clipboard

Commands executing in the context of a trigger invocation can currently access user-layer dynamic configuration (user specified in trigger definition or through request headers), but cannot access room-layer dynamic configuration.

It may be useful to create a trigger-specific layer that can be applied instead of the room layer when a command executes from a trigger.

A partial workaround for the time being would be to create a user for the trigger and assign them whatever credentials are needed in a user layer.

UPDATE Turns out that triggers currently behave as 1-on-1 messages with the bot: https://github.com/operable/cog/blob/c0041e439dee3c2213f28444d95f995cfec75a1d/lib/cog/chat/http/provider.ex#L51-L54. This means that triggers can currently be configured using the "room/direct" layer (in addition to a user-specific layer), but conflating direct human chats with triggers may not be what we ultimately want or need. Providing a specific trigger configuration layer may allow users to more tightly regulate how their triggers are executed.

Is the proposal to have a single trigger layer for all triggers effectively sharing config?

I'm having trouble thinking of a case where I'd need a separate layer of config that wouldn't already either be in the base layer or in some room layer. A trigger layer would solve the issue but seems like it would be duplicating config that already exists somewhere else.

Another idea: Since we already have the notion of running a trigger as a specific user, would it make sense to also provide an in_room attribute that would run the trigger with that room's dynamic config. This would also make it easy to test configuration of a trigger before creating it and wiring it up to external events.

I think in_room is preferable to introducing another configuration layer. The mental model is easy to grok -- "this trigger runs just as if I submitted it in the ops room". It also avoids duplicating configuration entries just to run a trigger which might grow stale over time.

It's not a single layer for all triggers; it'd be like a "special room" that triggers would execute in. You'd provide configuration for your bundles just like you would for other rooms.

Specifying a room would be similar; if there aren't trigger-specific needs, then that may be fine.

There may be weirdness due to the fact that we'd be referring to rooms from one provider in another one; I haven't fully refreshed myself on the current implementation, though.

If we go the in_room route, we may want to specifically call it config_from_room or something to avoid people thinking commands would be output in that room. Although now that I'm thinking about it, that could be nice. Probably a separate issue to discuss though.