-
Notifications
You must be signed in to change notification settings - Fork 27
Keep config.adapters.hipchat.rooms = :all #32
Comments
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 |
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 'XXXXX_dev@conf.hipchat.com'
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"] |
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? |
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:
Just to be clear - I can totally live without the Anyway - you know your code best, so I admit I only have half of the perspective. EDIT: |
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 |
Well, I think config instructions should take precedence over any other. If you treat it like this, I think everybody wins.
I say more advanced, because I dont think there is anything simpler than telling the bot "please join these rooms, and dont argue!" :) |
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. |
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 |
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. |
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.
The text was updated successfully, but these errors were encountered: