Closed vcastellm closed 10 years ago
This was an intentional decision. I agree that there is benefit to private chats, but in this case everything is shared anyway, so I'm not sure what we would gain? Since there's only support for one index naming (maybe a different issue), and there's no real auth involved (another issue), it seemed productive to force users to restore publicly.
I'm curious about your particular use case though, what's the advantage to privately manipulating indices? This update would certainly reflect a more 'huboty' way of doing things.
everything is shared anyway
What you mean?
I'm curious about your particular use case though, what's the advantage to privately manipulating indices? This update would certainly reflect a more 'huboty' way of doing things.
It's just that I'm the ops guy, and I don't want to bug other devs with my affairs with indices. And creating a room just for me and the bot seems redundant when I just want operate with him 1to1.
I got you. In the orgs where I've implemented, many devs used Kibana to investigate logs. In this case it always made sense to both:
Since the failure if multiple private restores occur is quick and easy, and the update is completely in line with Hubot best practices, I'll aim to implement as soon as I can.
I suggest to change
hear /^<command>
forhear /<command>
orrespond /<command>
Reason: It doesn't work in a 1 to 1 chat (private chat) in hipchat in my case.
I think hipchat appends some id at the beginning of the message in private chats that makes elk don't respond because it doesn't begin with ^elk.
Sometimes you don't want your coworkers to see your private conversations with your bot ;)