Keep config.adapters.hipchat.rooms = :all

[Danny Ben Shitrit]

I see that config.adapters.hipchat.rooms is deprecated, but I am unable to find a suitable alternative.

I have a simple bot that consists of only the config file, and a single plugin, so I do not have any place to specify the join event.

I am sure I am missing something obvious, but the documentation is unclear.

Also (as I saw in issue #10) I was trying to manually invite the bot to the room, and nothing happened.

I am posting here and not on StackOverflow mainly because I hope that some configuration option (that resides in lita_config.rb) will be provided instead of the deprecated rooms property, or at least any other option that does not require me to create the full blown bot directory structure.

[jimmycuadra]

Using the latest version of lita-hipchat, the rooms the bot is in is managed by sending it messages while it's running, rather than in configuration. This is the reason the configuration attribute is deprecated. If you're specifically looking for an equivalent of the "all" setting in the deprecated configuration, you're correct that there is no new equivalent. It's not really a safe default to have the bot automatically join every new room, since there may be reasons the bot is not wanted in a room, so it's intended that you opt-in to its presence in a room by inviting it manually.

It might also be useful to you to know that you can put any arbitrary Ruby code you want in Lita's configuration file, including defining a small handler for the purposes of adding a simple event handler. For maximum succinctness, you can use the block syntax to define the handler:

# in lita_config.rb

Lita.register_handler(:hipchat_room_joiner) do
  on :joined do |payload|
    robot.join(payload[:room])
  end
end

[Danny Ben Shitrit]

I see.

Is there a pure config option to still allow connecting to a list of rooms on startup, without the need to a) create a handler and b) write arbitrary ruby code in it? If no, and if we are counting votes, I would like to add mine to such a feature.

So far, I have worked around it by creating a handler that does this:

# Handler code
config :jid_prefix, required: true
config :rooms, required: true

# Join all rooms in the config on connect
# e.g. robot.join '[e-mail]'
on(:connected) do |payload|
  config.rooms.each do |room|
    robot.join "#{config.jid_prefix}_#{room}@conf.hipchat.com"
  end
end


# lita_config.rb code
config.handlers.myhandler.rooms      = ["dev", "devops"]

[jimmycuadra]

Having an initial list like you describe was discussed during the conversation to the new way of managing rooms, but was didn't seem to offer much benefit for the increased complexity and ambiguous behavior when combining both approaches. Can you share more about your use case? Why would file-based configuration be better for your purposes?

[Danny Ben Shitrit]

I understand. If things get complex because of this, than you are probably right in deciding to kill this feature.

There are a couple of reasons I am looking for simplicity in defining rooms to join:

1. If I am using a bot without body (a bot with only plugins, and no custom handlers of my own) then there is no place to define auto join behavior, other than to contaminate the lita_config.rb file with code that is more suitable to be in a handler. (specifically, I was using lita-cmd plugin which gave me a 'handler-less' way to add my own commands)
2. Even if I do have a handler (which eventually I had no choice but to go this way), then the join command does not work with a simple room name, it requires the full format of [e-mail] which is less than friendly. So this requires a more involved handling (something like I posted above) for the basic operation of joining rooms.
3. In the spirit of ruby, where it is expected to have complex tasks hidden behind simple DSL or config, I cant help but expect to have this "what rooms should the bot be in" action have a trivial, straight forward one liner for the users to write.

Just to be clear - I can totally live without the :all shortcut if it poses even more issues.

Anyway - you know your code best, so I admit I only have half of the perspective.

EDIT:
You say "combining both approaches" - what do you mean by that?
If I understand, you are referring to approach 1 being "join by config" and approach 2 "join on demand"? If so, I don't see how they conflict and it feels to me like they should co exist, there is a place for both of them.

[jimmycuadra]

Yes, that's what I meant by "combining approaches." If the list of rooms to join exists in both the config file and in Redis, then there is no single source of truth. Imagine the case where the config file lists rooms A, B, and C. You start the bot, and then send it a command to leave room C. It leaves and persists the change to Redis. The next time the bot process is started, there is conflicting information about whether or not to join room C. While the config file could be used for "list on rooms to join on the very first run of a new Lita instance" functionality, the usefulness of defining it in the configuration at that point at all is hard to argue, and it would be more confusing than just giving up one approach for the other.

Regarding your second point, and somewhat by extension your third point, in the latest version of Lita you should be able to use the simple name of the room as it appears in the HipChat app for the "join" and "part" commands rather than the JID (the email address looking format). The implementation of those commands in Lita::Robot attempts to look up a Lita::Room object for whatever string ID is passed in, and should be able to find it based on its name. If it doesn't, that means a room object for the room was not persisted to Redis for some reason, which can be fixed by restarting the bot. It should be picking up and persisting new rooms as they're created, though. If it doesn't, that's a bug!

[Danny Ben Shitrit]

Well, I think config instructions should take precedence over any other.
If I tell the bot to join rooms [A, B], and the bot is restarted for any reason, it must join rooms A and B regardless of any other source.

If you treat it like this, I think everybody wins.

1. People like me who dont care about the redis persistency, and only care that the bot is always at predefined (if not all) rooms, I can define it in the config
2. People who want it the other way around - which arguably, is the more "advanced" type of use - can simply NOT use the config, and join/part their rooms whenever and wherever they wish.

I say more advanced, because I dont think there is anything simpler than telling the bot "please join these rooms, and dont argue!" :)

[jimmycuadra]

Even if the configuration file overrides anything stored in Redis, it's not necessarily obvious that it would work that way – a user could easily send a command to part from A or B and then be confused why it joined again on the next launch. It's simply ambiguous to have two sources. I'm still not very clear on the benefit of managing it in the configuration file. We moved away from that approach in large part because it was often complained about as cumbersome, and with good reason.

[Danny Ben Shitrit]

Well, its your call of course, but now you can say that people complained about that deprecation as well...

For me, the Redis dependency in lita was quite a turn off in the first place. I was looking for a simple bot that responds to commands and do not understand why it needs to store anything at all - but thats a different story and probably due to my lack of understanding of the inner workings of lita.

For the record, if we want to wrap this topic up, I do not like the fact that there is no easy (as in config.rooms = [A,B]) way to auto join rooms. I feel that if there is anything that blocks such a feature, then its a case of the tail wagging the dog and the source itself should be handled instead of letting it block such basic functionality.

[jimmycuadra]

I am still not seeing any reasons why it should work that way other than that you don't like it. I'm going to close the issue for now but would be happy to entertain additional use cases.