Currently, users can be looked up only by ID or name. ID is annoying for chat services where you may not know the ID offhand, e.g. HipChat or IRC. Name is problematic because it has to be typed exactly, which sometimes requires quoting the name, and sometimes won't match exactly what's stored in Redis.

There should be a fuzzy user look up method that makes it easy for plugins to look users up by a key that could be ID, name, mention name, or a fuzzy match of name.

RSpec matchers that wrap message expectations currently give unhelpful errors like:

Exactly one instance should have received the following message(s) but didn't: foo

They should speak in the right context:

Expected message "bar" to route to :foo, but didn't.

The default command should either be "help" or it should be contextual based on whether you're in a project or not.

If the plugin creator says they want to build on TravisCI and they want code coverage, then why not add the badges to the readme?

[![Build Status](https://travis-ci.org/webdestroya/lita-excuses.png)](https://travis-ci.org/webdestroya/lita-excuses)
[![Code Climate](https://codeclimate.com/github/webdestroya/lita-excuses.png)](https://codeclimate.com/github/webdestroya/lita-excuses)
[![Coverage Status](https://coveralls.io/repos/webdestroya/lita-excuses/badge.png)](https://coveralls.io/r/webdestroya/lita-excuses)

For more complex commands, it would be useful to be able to include keyword arguments as part of the message so that order doesn't matter and parts of the commands can be optional.

For example, a message like this:

Lita: foo bar=baz this_key="has a quote-delimited value"

Could have its keyword arguments accessed by a handler:

message.keyword_args[:bar] # "baz"
message.keyword_args[:this_key] # "has a quote-delimited value"

It might also be worth supporting different characters in place of the =, since there is precedent for this, for example in lita-datadog, which uses a : and requires that the values be quoted. /cc @esigler

Is there a way to have the bot respond to slash commands instead of the full @mention name? I'm looking for something like:

/help

Instead of:

@Mybot help

See b752132#L0R77

sparked from the conversation at litaio/lita-hipchat#7.

To allow plugins to provide adapter specific rich formatted messages we can borrow the Rails pattern for view templates.

The plugin can provide templates that follow the pattern: HANDLER.ROUTE.ADAPTER.erb, where:

HANDLER = registered handler class name
ROUTE = the method symbol passed to #route
ADAPTER = the adapter name (hipchat, slack, shell, etc)

For example, the lita-jira plugin can provide hipchat and slack specific templates like so:

jira.issue_details.hipchat.erb
jira.issue_details.slack.erb

If the argument sent to Response#reply is a hash, it's the context variables to use in a template, otherwise fall back to old behavior which is a text message

If the adapter being used doesn't have a template, then the hash should provide a fallback message string which would be the same message string that's passed now.

This would allow plugin authors to provide rich response templates, but existing ones continue to work sending plain text.

See litaio/lita-hipchat#5.

Feature request: I would like to be able to access information about the users in a chat room (roster). Currently this appears to be possible only with some hackery such as the following

robot.instance_variable_get(:@adapter).connector.roster.items

Because some functionality (notably config.robot.admins) require a user's primary ID, which is unique, there should be an easy way of finding out what a given user's ID is. This is often not easy to get, such as on IRC and Slack. Perhaps a built-in handler that worked something like this:

You: Lita, users find carl
Lita: Carl the Pug, ID: U0123456789

Try adding yardstick to the build to verify documentation coverage.

Try adding RuboCop to the build for additional automated code style enforcement. Can probably replace Cane.

lita-xmpp breaks almost all other plugins as it depends on lita 2.x

It also looks like the plugin hasn't been maintained in a long time, perhaps someone else with the required skills to update it?

I have also logged a ticket with jmazzi/lita-xmpp/issues/6

We have a slack user with a mention_name jose and a real name Jose Pantíno (accent over the i)

The following crashes the Authorization Handler:

@lita auth add jose testgroup

...with the following:

[2014-12-20 06:24:09 UTC] ERROR: Lita::Handlers::Authorization crashed. The exception was:
"\xC3" on US-ASCII

It seems the handler cannot deal with special characters. (I am assuming this is a lita issue and not a lita-slack issue.)

When a Robot is created, it should get a (possibly immutable?) copy of the registered handlers rather than accessing them directly from Lita.adapters and Lita.handlers.

Add methods allowing code to be executed after a delay or at recurring intervals, a la JavaScript's setTimeout and setInterval. Use Timers.

I'd like to be able to run the same robot on both IRC and Campfire (and ideally any number of other services). The robot should share persistence across both services.

For example, using lita-karma:

Campfire-me> something~~
Campfire-Lita> something: 0
IRC-me> something++
Campfire-me> something~~
Campfire-Lita> something: 1

Consider adding functionality for Lita to execute code at specifically scheduled times, a la cron. See the prototype at lita-schedule.

/app/vendor/bundle/ruby/2.0.0/gems/lita-3.0.3/lib/lita/version.rb:3: warning: already initialized constant Lita::VERSION
/opt/rubies/2.0.0-p247/lib/ruby/gems/2.0.0/gems/lita-3.0.3/lib/lita/version.rb:3: warning: previous definition of VERSION was here

Hey Jimmy,

Just wanted to open a quick issue to let you know that the GitHub page for Lita (https://jimmycuadra.github.io/lita/‎) redirects to www.lita.com not www.lita.io. I know this isn't a direct issue with the project, but wasn't sure of the best method for communicating the problem to you.

I was admittedly pretty confused when I first got redirected to lita.com.

Cheers!
-Tim

I was sort of thinking this when it was first proposed, but wasn't totally sure and unfortunately didn't say no. Daemonization logic is not an application concern and should not be handled in Ruby code by Lita. There are plenty of process management tools available to do this for arbitrary processes without needing the application itself to be aware of how it's being run.

Lita::Daemon should emit a deprecation warning in Lita 4 and should be removed in Lita 5.

Further reading: http://www.mikeperham.com/2014/09/22/dont-daemonize-your-daemons/

Use pretty colors to help distinguish the user's input from Lita's output in the shell adapter.

I just started playing with Lita and I'm excited about the potential, but I have a couple questions:

Q: What is the proper way to daemonize? How Do I stop/restart Lita?

Currently I have LaunchControl running bundle exec Lita -d in the appropriate directory. A previous issue says that will be deprecated and to use an OS specific process manager, but what command would I run with that process manager? and how would I stop/restart Lita?

Q: If you try to tell Lita to do something it isn't aware of, you get nothing. This is kind of useless for new users.

Would it be possible to output something like I do not know about that command. Try 'Lita help' for a list of available commands

Thanks!

Currently, you can do the following:

module Lita
  module Handlers
    class Buzzwords < Handler
      route /buzzwords?/i, :buzzword
    end

    Lita.register_handler(Buzzwords)
  end
end

require "spec_helper"

describe Lita::Handlers::Buzzwords, lita_handler: true do
  it { routes("buzzwords").to(:buzzword) }
  it { routes("buzzword").to(:buzzword) }
end

And tests pass. I think it shouldn't as there isn't a method called buzzword yet.

Extract UI messages into i18n files.

Hello,
is it possible to send a reply with the bot which is HTML markup ?
I would like to send messages to the HipChat room with html markup language in certain plugins, and I can do that using the HipChat API.
Is there some way to make an extension for this ?

Thanks.

is there way to run some kind of "ilta say blah" to use lita from a shell. i'd like to use it to send some notifications from example from monit. If not, i can try to implement that feature, if it's needed

Is it possible for a handler to know from what adapter the message it is processing was received?

@leejones and I have been experimenting with Lita, and we wrote a toy plugin lita-vader. We're using Slack for chat, which will notify a user if a message in a channel contains their username in the special format <@username>. Thus when lita-vader is being used with Slack we would like it to say <@username>, I am your father!. However, since other services do not benefit from this special syntax we would just like it to just say username, I am your father! by default.

We thought perhaps we could determine the adapter from the objects exposed in the handler, but after poking around we did not see a way.

HTTP routes with named parameters would be a nice feature to have in Lita, the same way Hubot or Sinatra do it:

http.get "/lita/my_handler/:foo", :my_method

would turn the route in regex form /\/lita\/my_handler\/(.*) (simply put), and a call like

GET /lita/my_handler/bar HTTP/1.1

would populate request.params in my_method with { "foo" => "bar" }

Timers should be executed in a thread so they don't block the execution of code that comes after them in handler methods.

When users type the help command, it lists help for all the auth settings. Is there a way to disable or customize this? It's a little too verbose for users to see every time.

Lita.config is currently a big ball of global state, shared by all handlers. This is bad. The config should be frozen, probably with ice_nine or adamantium.

Hi there,

would you mind to use the Ruby-readline-module for the shell-adapter (for supported platforms)? This should give you a history etc. and commands like "^P" should work.

http://www.ruby-doc.org/stdlib-2.1.0/libdoc/readline/rdoc/Readline.html.

Cheers.
maxmeyer

I'm trying to set Lita to launch on boot (server) in crontab but it is not working. What am I doing wrong?

@reboot cd /lita ; /usr/bin/screen -dmS lita /usr/local/rvm/gems/ruby-2.1.0/bin/lita

i assume cron does not have the right ENV but I used absolute paths

For months, https://docs.lita.io/ has not been working. I start to wonder if I should invest time in Lita as it looks like it's dead in the water.

Hey there, a fresh install lita isn't answering.

[troy@Macintosh lita]$ ruby -v
ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-darwin13.0.0]
[troy@Macintosh lita]$ lita 
Type "exit" or "quit" to end the session.
Lita > lita
Lita > Lita
Lita > 
Lita > help
Lita > 
Lita > 

What did I miss?

If a given configuration entry (say config.adapter.password) isn't defined in lita_config.rb, lita should check the environment variable $LITA_ADAPTER_PASSWORD as well.

When generating a plugin, ask for the owner/repo name (if the account is being hosted on GitHub) and add badge markup for any services they've selected.

Howdy! I know the window is closing for Lita 4.0, so apologies in advance if this is possible and I just haven't seen it yet - Would it be possible / reasonable to be able to store metadata about a user that is cross-plugin accessible?

For a concrete example, @theckman's Github plugin will soon be able to store a per-user OAuth token. I have a different not-yet-released plugin that will also need a users's Github OAuth token to take certain actions. It would be nice to be able to share that information without having to make a specific agreement between the two plugins.

It kind of seems like this would be possible by re-creating the user with new metadata, like in the current spec, but is that recommended?

I need a way to make http handlers authenticate requests. Looking through the code it looks like the place to configure the rack app would be here. Do you have any thoughts or suggestions about another (easier) way to do that? Otherwise would you be open to a PR adding support for a config option? Thanks!

The shell adapter should handle control-D gracefully.

Code Climate supports test coverage tracking and badges now, so there's no need to use Coveralls. This also encourages people to do code quality tracking, which the generated plugins currently don't give you a choice about.

Looks like new things are going over to the litaio organization, so it might be worth transferring this repository over there.

Redirects, both in terms of viewing in a browser or using a git client, are handled automatically after transferring (see https://help.github.com/articles/transferring-a-repository/ and search for redirect).

Is there any way to reply directly to the user who typed the message to the bot? user.name is their full name and you can't access their display name?

Maybe this exists and I've just overlooked it.

The use case I'm thinking of is when a route has group set via :restricted. I think at the moment, Lita just ignores it. In the case of writing lita-rundeck, I wanted to be able to tell the user why it didn't respond and how to resolve it instead of thinking the user thinking they got the message format wrong. (I solved it like this: http://goo.gl/XrO83U)

Two thoughts on this:

• Lita could just give some generic message about the restriction. i.e. "Sorry, you aren't authorized for this command."
• Maybe by default is the status quo, but the internals actually call a method (that does nothing by default to maintain the status quo) and that Handler developers could then override?

block would be the equivalent of the method of the same name as the route

Lita does not fail in an obvious way when it can't make a connection to Redis or when Puma tries to bind to an unavailable IP/port. These errors should output some sort of fatal error that the user can see to determine the issue right away.

It would be really nice if I could do something like:

$ lita handler lita-stuff

and it would make a skeleton gem for me, it would make the gemspec, the folders

lib/lita/lita-stuff.rb
lib/lita/handlers/stuff.rb
spec/lita/handlers/stuff_spec.rb
lita-stuff.gemspec
LICENSE
README.md
etc

that would be super useful, since doing that becomes very redundant

Fresh install on a new ec2 instance.
Prior to this I had run:

• sudo yum install openssl-devel.x86-64
• sudo gem2.0 install lita
  Then, to create a new lita configuration:

~ $ lita new
/usr/share/ruby/vendor_ruby/2.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- io/console (LoadError)
    from /usr/share/ruby/vendor_ruby/2.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /usr/local/share/ruby/gems/2.0/gems/thor-0.19.1/lib/thor/shell/basic.rb:2:in `<top (required)>'
    from /usr/share/ruby/vendor_ruby/2.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /usr/share/ruby/vendor_ruby/2.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /usr/local/share/ruby/gems/2.0/gems/thor-0.19.1/lib/thor/shell/color.rb:1:in `<top (required)>'
    from /usr/local/share/ruby/gems/2.0/gems/thor-0.19.1/lib/thor/shell.rb:17:in `shell'
    from /usr/local/share/ruby/gems/2.0/gems/thor-0.19.1/lib/thor/base.rb:439:in `start'
    from /usr/local/share/ruby/gems/2.0/gems/lita-3.2.0/bin/lita:6:in `<top (required)>'
    from /usr/local/bin/lita:23:in `load'
    from /usr/local/bin/lita:23:in `<main>'
~ $

A bit of hunting suggested that I needed to install the io-console gem. After installing that gem:

~ $ lita new
      create  lita
      create  lita/Gemfile
      create  lita/lita_config.rb
~ $

The list of gems installed after io-console was added:

activesupport (4.1.1)
bigdecimal (1.2.0)
bundler (1.6.2)
faraday (0.9.0)
ffi (1.9.3)
hashie (3.0.0)
http_router (0.11.1)
i18n (0.6.9)
ice_nine (0.11.0)
io-console (0.4.2)
json (1.7.7)
lita (3.2.0)
minitest (5.3.4)
multi_json (1.10.1)
multipart-post (2.0.0)
mumble-ruby (1.0.2)
opus-ruby (0.0.1)
psych (2.0.0)
puma (2.8.2)
rack (1.5.2)
rdoc (4.0.1)
redis (3.0.7)
redis-namespace (1.4.1)
ruby_protobuf (0.4.11)
thor (0.19.1)
thread_safe (0.3.4)
tzinfo (1.2.1)
url_mount (0.2.1)